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e were all born 
into this world 
naked and helpless, 
and that's a bit 
how I felt when I 
first came to Game Developer five years 
ago as a young, know-nothing editorial 
assistant. Well, I did know some things, 
but trust me, they weren't about game 
development. What I learned from that 
point forward has changed my life not 
only by teaching me new things and new 
ways to think about them, but also by 
introducing me to a development com- 
munity teeming with more gifted, 
thoughtful, and generous people per 
capita than may exist anywhere else. 

Now, after five years at Game 
Developer^ my time has come to move 
on and learn more new things, which I 
am hoping won't feature an unrelenting 
battery of monthly production deadlines. 
It's not been an easy decision at which to 
arrive, of course. I'll miss turning the 
brainchildren of clever minds into glossy 
printed pages that they can show off to 
Mom. My job has been pleasurable pri- 
marily due to the professionalism and 
generous esteem of the hundreds of writ- 
ers I've dealt with over the years and the 
thousands of enthusiastic readers I've 
heard from and met. 

Writing this column each month was 
not exactly something I looked forward 
to, but I always tried not to waste the 
space allotted to me (okay, space which I 
allotted to myself), and for that I've cov- 
ered a lot of ground, from business to 
politics to publishers to matters of craft. 
So, at the risk of repeating myself here 
and there, let me touch on some of the 
major trends I've seen transpire in the 
game industry in the past five years. 

For one thing, most of you have gotten 
a lot better at your jobs, whether spurred 
by rising expectations, abject fear, or just 
practice. While some production gaffes 
continue to appear in Postmortems with 
frustrating frequency, many other com- 
mon development pitfalls have been 



incrementally improved upon to where 
they are now — gasp! — manageable. 

Also, you've gotten more confident in 
your professional identity. Maybe you 
still can't explain your job to your par- 
ents or make them understand that it 
even is a real job, but you're heroes to 
more and more young people who want 
to grow up to be game developers. 

On the downside, after five years too 
many of you are still letting yourselves be 
marginalized or trivialized in a main- 
stream context. Keep demanding more 
professional marketing and PR activities 
for your games on par with other high- 
profile entertainment products, not pro- 
motional materials that evoke monkeys 
and typewriters. 

Finally, apathy among game develop- 
ers at regulatory efforts and political 
witch-hunts is at an all-time yawn. Your 
creativity and freedom are being threat- 
ened. Just because you create fantasy 
worlds doesn't mean they won't be sub- 
ject to a heavy dose of reality at some 
point. Even though I may suffer some 
initial separation anxiety, rest assured 
that Game Developer remains in fine 
hands. The editorial team has some very 
exciting changes coming down the pike, 
but I don't want to give too much away 
yet, so stay tuned. 

In addition to all the regular colum- 
nists who labored month after month 
under my cruel hand, I'd Hke to thank 
the whole advisory board for their self- 
less contributions, and I especially thank 
Jeff Lander, Jonathan Blow, Hal 
Barwood, and Dave Pottinger for being 
extra generous with insightful feedback 
and for each having a delightful way of 
delivering it. This magazine owes much 
to everyone who's contributed to it in 
ways big and small over the years. 
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KEEPING AN EYE ON THE GAME BIZ | kenneth wong 



Nintendo releases scant details on new device. 

Nintendo spilled a few specifications of its 
upcoming handheld Nintendo DS, sched- 
uled to debut at E3 this year. Nintendo 
president Satoru Iwata's statement that 
Nintendo DS is "based upon a completely 
different concept from existing gaming 
devices" diminished speculations of the 
new device simply being an enhanced 
Game Boy Advance. Though Nintendo 
spokesperson Yasuhiro Minagawa claims 
that they're not trying to take on PSP, 
industry watchers consider the Sony PSP a 
serious competitor to Nintendo's handheld 
products. Nintendo's announcement 
describes a device with "two separate 3- 
inch TFT LCD display panels, separate 
processors, and semiconductor memory of 
up to 1GB." No photo or prototype was 
available at press time. 

Kevin Bachus to make the Phantom material- 
ize. Infinium Labs appointed Kevin 
Bachus, the cofounder of both Microsoft 




Will games developed for the current Xbox 
(shown here) be playable on the new Xbox? 

Xbox and Capital Entertainment Group, 
as its president and COO. Bachus's imme- 
diate focus is to launch the Phantom 
Gaming Services, the company's broad- 
band game-rental program. Even though 
Bachus's arrival lends some legitimacy to 
the Phantom project, many are still highly 
skeptical of the elusive game console, 
whose debut at CES in January 2004 
proved to be a non-operational mockup. 

Avid gains access to Alienbrain. Avid 
Technology acquired the Munich-based 
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AND OTHER STUFF 




SN Systems delivers PS2 debugger SN 

Systems released Proview Plus for the 
Playstation 2 console, a postmortem 
debugger that works with Sony's latest 
development hardware (DTL- 
H3010''-LT). The software-based 
debugger communicates with the con- 
sole via the Fire Wire port, leaving both 
the Ethernet and USB ports available 
for use by the game. It requires 
Windows 2000 or XP, a FireWire port, 
and Sony's development hardware. 
Proview Plus is available for 
$l,000-$7,200. www.snsys.com/ 
PlayStation2/Pro ViewPlus.htm 

IDV plants Speedtree RT L6. Interactive 
Data Visualization released Speedtree 
RT 1.6, a tree design and simulation 
editor/middleware. The new version 
includes enhanced lighting realism and 
trunk design, along with efficiency 
improvements. Other key new features 



include: Bump-mapping and self-shad- 
ow lighting effects, 360-degree bill- 
boarding for smoother transitions, 
improved root/branch detail, and new 
library additions, bringing the total to 
80 species, www.idvinc.com/html/ 
speedtreert.htm 

Macromedia launches Director MX 2004. 

Macromedia announced Director MX 
2004, the latest version of its multime- 
dia development and prototyping tool. 
New features include support for JAVA 
script in addition to Director's existing 
Lingo script, better integration with 
Flash, support for nonlinear DVD play- 
back, and better playback of Quick- 
Time, Windows Media, Real, and AVI 
files. Director MX 2004 is available as 
an upgrade from Director 8.5 or MX 
for $399 or standalone for $1,199. 
www.macromedia.com 

— Peter Sheer in 



NXN Software, which offers asset and 
production management systems for the 
entertainment and computer graphics 
industries. The acquisition gives Avid's 
customers access to NXN's Alienbrain, 
supported by Alias, Discreet, Softimage, 
and other digital content-creation pack- 
ages. Designed for workflow manage- 
ment, the Alienbrain product line fits into 
Avid's current strategic motto: "make, 
manage, and move media." 

Microsoft leaks next-gen Xbox details. 

Microsoft leaked to the press some tenta- 
tive specifications for its next-generation 
Xbox. Whereas the current Xbox features 
an 8 GB hard disk, the new console will 
likely include none; users may rely on 
flash memory to store saved files (as with 
the Playstation 2). Microsoft was reluctant 
to say whether the new ATI-powered 
Xbox would be backward compatible 
with the current Nvidia-powered Xbox. 
The unofficial nature of this announce- 
ment leaves Microsoft room to reposition 
the new console with additional compo- 
nents, should competitor Sony introduce 
^ the Playstation 3 with far more advanced 
features. The next Xbox is set to appear 
in 2005, and Playstation 3 in 2006. # 

Send all industry and product release news 
to neivs@2dmas:.com. 




UPCOMING EVENTS 



GAMER TECHNOLOGY CONF. 
Westin Seattle Hotel 
Seattle, WA. 
March 11-12, 2004 
Cost: $895 

www.lawsenninars.conn/htmls/ 
senninars04/04gannewa/ 

SOUTH BY SOUTHWEST: 
MUSIC AND MEDIA 

The Austin Convention Center 

Austin, TX. 

March 12-21,2004 

Cost: $225-$775 

www.sxsw.com 
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PRODUCT REVIEWS ^ 

THE SKINNY ON NEW T(ypL2 

Borland's JBuilder 
Mobile Edition 

by ralph barbagallo 



Mobile game develop- 
ment is hot. That does- 
n't mean many people 
are actually making 
money in the market, 
but nonetheless, it's big. Major publishers 
such as Activision and THQ have stepped 
up to the plate, along with a host of new- 
comers, to bring content to carriers world- 
wide. Sun's J2ME platform is deployed on 
the most carriers, with thousands of devel- 
opers producing a seemingly infinite array 
of games for handsets of all types. 

Surprisingly, there isn't a thriving mar- 
ket for J2ME development tools. With 
Metrowerks' CodeWarrior Wireless Studio 
languishing without updates, Borland has 
stepped into the vacuum with an afford- 
able J2ME IDE— JBuilder 9: Mobile 
Edition. Sporting the familiar JBuilder 
interface, Borland has put together a great 
package that's even cheaper than Code- 
Warrior, for $399. You may have to look 
really hard, however, JBuilder Mobile 
Edition just isn't very widely available. 

JBuilder has a long history as a tool for 
J2SE developers. Therefore, the interface 
of the IDE should be familiar to those 
who have used previous versions of 
JBuilder. To the uninitiated, JBuilder is far 
less complicated than Code Warrior's 
somewhat Byzantine interface, but not as 
fast or slick as Microsoft's VisualStudio. 
The GUI is also curiously slow, with 
redraws and refreshes occasionally being 
heavily delayed even with 512MB of 
RAM (Borland suggests a full 1GB of 
RAM for optimal performance). 

Yet, after reading through the brief on- 
line documentation, I was up and running 




JBuilder's interface is less complicated than 
CodeWarrior's, but not as fast as VisualStudio's. 



in no time. Creating a simple "Hello 
World" MIDlet was easy as pie. And con- 
verting my old Sun Wireless Toolkit proj- 
ects to JBuilder was just as simple once I 
got the hang of it. All I had to do was cre- 
ate a new project and start copying files 
over. In addition to manually copying files 
and adding them to the project, JBuilder 
provides a number of wizards to set up 
default projects and simplify the task of 
getting started. 

Speaking of wizards, JBuilder has a 
number of unique features that can help 
when developing more complicated 
MIDlets. One in particular is the UI 
designer. Even though J2ME's Icdui pack- 
age is pretty bare-bones as far as GUIs are 
concerned, JBuilder allows you to specify 
the GUI components of a screen and will 
generate the code and classes automatical- 
ly. It will also analyze the code and then 
display a diagram that shows you which 
screens link to which. This not only helps 
you visualize your program, but also helps 
you spot errors in your GUI logic that 
may make screens inaccessible or other- 



wise unusable. This tool really simplifies 
the task of setting up mundane GUI code 
and lets you get to the real meat of devel- 
opment (that is, if you actually use J2ME's 
ugly and inflexible GUI classes). 

One of the great innovations of 
Wireless Studio was the ability to select 
between multiple JDKs to support each 
handset's unique API. JBuilder mimics 
this ability with the JDK Configurator. 
Here you can point JBuilder at the folder 
in which the desired API is stored, and it 
will automatically find the classes, 
libraries, and emulators. You can then 
pick the SDK you want to use for this 
project, not to mention switching it at 
any time to make builds of your project 
for specific SDKs. 

As for other J2ME-specific features, 
JBuilder allows for extensive editing of the 
JAD file. This includes creating your own 
custom fields and values. In addition, 
JBuilder provides support for third-party 
obfuscators, including Retroguard. Also, 
any third-party emulator can be used and 
custom command-line parameters can be 
set for each one. JBuidler also supports 
ANT, so you can create your own custom 
scripts for just about any purpose. This 
comes in handy when having to make 
handset-specific builds that may require 
the inclusion or exclusion of certain files 
for certain handsets (such as art assets), or 
omitting various classes. 

JBuilder's source-level debugger is quick 
and responsive, not to mention full-fea- 
tured, with a standard array of break- 
points, watches, and other tools. In com- 
parison, CodeWarrior's debugger is laggy, 
and even buggy at times where it fails to 
stop at certain exceptions and has a hard 
time refreshing variable values. Unfor- 
tunately, CodeWarrior's trailblazing on- 
device debugging feature is absent from 



RALPH BARBAGALLO I Ralph runs FLARB (www.flarb.com), a game studio in Southern 
California specializing in wireless games. He is the author o/^ Wireless Game Development in 
C/C++ with BREW (Wordware Publishing) and is currently working on a MIDP 2.0 book. 
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JBuilder. Even though in the case of 
CodeWarrior it only worked on one or 
two handsets, it is an excellent feature 
that Borland should really look into for 
upcoming versions. 

Much like CodeWarrior, JBuilder fea- 
tures in-IDE support for third-party 
source control programs, including the 
widely used open-source tool, CVS. Other 
big-time development features touted in 
the documentation include UML diagram- 
ming, although that's only available in the 
more expensive Enterprise Edition. 

Once again, a J2ME IDE is here with 
not much to compete against. I heartily 
recommend this over CodeWarrior 
Wireless Studio. With JBuilder 's snappy 
interface, a plethora of features, and a 
very low price, I don't think anyone will 
be missing Metrowerks from this space. 
It's unfortunate, as some advanced fea- 
tures such as on-device debugging are 
still absent from JBuilder. We'll have to 



JBUILDER MOBILE ED. 



O STATS 

Borland Software Corp. 
Scotts Valley, Calif. 
(831)431-1000 
www.borland.conn 

PRICE 
$399 

SYSTEM REQUIREMENTS 

Intel Pentium IIMOOMHz or equivalent, 
256MB of main memory (512MB recom- 
mended), Windows 2000 or Windows 
XP 1 .9GB of free hard drive space (full 
install). 

OPROS 

1. Intuitive and streamlined interface. 

2. Easily switch between JDKs. 

3. Innovative new tools such as the Ul 
Designer. 

O Cons: 

1. No on-device debugging. 

2. Lack of UML support. 

3. A very hard to find product. 



see how much continuing support 
Borland affords JBuilder Mobile Edition 
given its scarcity. If you are an existing 
CodeWarrior user, there may be no com- 
pelling reason to switch. However, con- 
sidering that heavyweights such as Sony 
Ericsson and Nokia have embraced 
JBuilder as a prime development tool for 
their respective handsets, it may be time 
to reconsider. 

3DConnexion's 
S p ac eTr ave I e r 

by sean wagstaff 

If you work in 3D, navigation in space 
probably occupies far more of your day 
than you realize. But just as a painter 
doesn't give much thought to how he 
positions his brush on the canvas, experi- 
enced 3D artists don't really think about 
moving around in three-dimensional 
space. Unless you're using an unfamiliar 
application, say, switching from Maya to 
3DS Max, navigation is simply an integral 
part of what you do and there's not much 
room for improvement. Or is there? 

The $599 SpaceTraveler, which looks 
like a volume control knob (complete with 
a purple LED accent on the buttons 
around its rim) is designed to make 3D 
operations faster and more intuitive. 

Using the SpaceTraveler is almost 
immediately familiar. You plug it into 
your USB port and install the driver soft- 
ware (plug-ins are provided for Maya and 
Max, and built into MotionBuilder, 
Cinema 4D, and BodyPaint 3D, but the 
controller doesn't work with every 3D 
tool). To use it, you simply push, pull, tilt, 
and twist the single knob. Your finger 
movements translate directly into 3D 
space — X, y, and z rotation and transla- 
tion, often referred to as six degrees of 
freedom — in your application. Lift the 
knob and you move up in y, push it for- 
ward and you move forward in z. Twist 
the knob and you'll rotate in y; tilt it, and 
you'll pitch forward or back, left or right. 
The tricky part is learning not to translate 
on z when you pitch on x, and not to 
translate on y when you actually mean to 
roll on ^ (a temporary filter can be turned 




The intuitive SpaceTraveler 3D controller 

on that blocks non-dominant movements). 
But with a few minutes worth of practice 
to get a feel for it, the SpaceTraveler 
becomes very natural to use, although it is 
quite sensitive to even fine movement. 
However, you'll soon find yourself tum- 
bling a scene around as easily as you 
would with your standard keyboard and 
mouse combinations, and rotating a cam- 
era is certainly more intuitive than, say, 
SHFT-CTRL-ALT-middle-mouse dragging. 

Which brings us to the most obvious 
question about this device: who needs it? 
If you're already comfortable working in a 
3D application, and navigation with the 
standard key commands and mouse 
actions has become second nature, why 
bother with yet another input device? In 
my experience, many 3D operations, such 
as architectural modeling, dynamics, and 
texture manipulations, simply require too 
much keyboard input to benefit from the 
SpaceTraveler at all. I need my hands on 
the keyboard, and mouse, and instant 
access to pop-ups and marking menus 
provided by my right mouse button, 
which just doesn't leave enough hands for 
a third input device. 

On the other hand (literally) when it 
comes to operations that require one- 
handed navigation, the SpaceTraveler is a 
terrific idea. For example, when sculpting 
an organic model or painting textures on 
surfaces with a Wacom tablet, you can 
rotate and tumble the model with one 
hand, while painting with the other. While 
doing character animation, the Space- 
Traveler can be used as a low-speed 
motion capture input device that lets you 
use gestures, rather then explicit rotations, 
to move a joint, although you'll have to 
set up your characters to work with this 
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input. The device's eight 
buttons can be mapped to 
common keyboard short- 
cuts, and the defaults for 
Maya activate the Hot 
Box, translate, rotate, and 
scale commands. However, 
the buttons are too small with terrible 
ergonomics, and I still need to use the 
keyboard for other commands, such as 
the marking menus. 

The SpaceTraveler, as the name implies, 
is small and portable. Although on-the- 
road walkthroughs of real-time-3D scenes 
seem unlikely, I found the SpaceTraveler 
useful as an accessory to a high-end 3D 
laptop for bringing work home. My 
Compaq runs all my 3D applications, but 
the built-in trackpad is all but useless for 
3D navigation, and the keyboard is 
cramped, with a non-standard layout, 
which also makes navigation clumsy. The 
SpaceTraveler really improves the usability 
of that machine on the go. 

I wouldn't recommend the Space- 
Traveler to everyone. After all, if you're 
already comfortable navigating in your 
predominant 3D application, you proba- 
bly don't need it. However, if you do a lot 
of work that requires one-handed naviga- 
tion, the SpaceTraveler may be a welcome 
arrival to your world. 

Jl^f ^ \ I SpaceTraveler 
SDConnexion 
ww.3dconnexion.com 

Sean is a freelance 3D artist. You can 
reach him at www.wagstaffs.org. 



Collision Detection in 
Interactive 3D Environments 
by Gino van den Bergen 

reviewed by jeremy jessup 

In Collision Detection in Interactive 3D 
Environments, (Morgan Kaufmann, 
November 2003), Gino van den Bergen 
explores the algorithms necessary to deter- 
mine whether polygonal intersections 
occur in a real-time interactive simulation. 
Available for $59.99, the book spans 277 



pages through seven chap- 
ters and includes a CD- 
ROM containing the 
source code to SOLID 3.5 
(Software Library for Inter- 
ference Detection), a colli- 
sion-detection library for 
interactive 3D animation. 

After the first chapter's brief introduc- 
tion, the second chapter details the 
required concepts of the text. Generally, 
the collision-detection algorithms present- 
ed in the book operate on convex objects. 
Methods are described to decompose com- 
plex shapes into various convex primitives 
such as spheres, triangles, and boxes. 
Some consideration is given to collision 
response, performance optimizations 
through frame and geometric coherence, 
and problems arising from floating point 
error in calculations. The chapter is heavy 
in mathematics and notation and makes 
for a slow and sometimes tedious read. 

Chapter three introduces algorithms for 
various types of primitive collisions 
through four broad categories: spheres, 
axis-aligned boxes, separating axes, and 
polygons. Each category contains an algo- 
rithm for various primitive combinations. 
For example, under the sphere category 
the routines presented are sphere to 
sphere, ray to sphere, and line segment to 
sphere. Each algorithm is well described 
mathematically, then some pseudo-code is 
provided to illustrate the implementation. 
However, each category's primitive combi- 
nation type presents just one algorithm. 
While other sources for algorithms are 
well-cited throughout the book, it would 
have been beneficial to compare multiple 
collision algorithms based on various sce- 
narios to explore the topic completely. 
The SOLID library uses the routines cho- 
sen and presented in the text. 

Chapter four is on convex objects, 
and Van den Bergen considers both sin- 
gle-shot and incremental algorithms 
designed to perform several types of 
proximity queries on polytopes. In par- 
ticular, each algorithm's computational 
complexity is provided and references 
are given for additional detail. The bulk 
of the chapter is devoted to discussion of 



^ ^ ^ ^ ^ excellent 

^ ^ ^ ^ very good 

^ ^ ^ average 

^ ^ disappointing 

^ don't bother 

the Gilbert-Johnson-Keerthi (GJK) algo- 
rithm, which is used to determine dis- 
tance and collision of general convex 
objects. The GJK algorithm is an itera- 
tive distance routine but can also be 
applied to general convex objects. 

Chapter five discusses data structures 
that reduce the scope of collision calcula- 
tions during run-time. Through a combi- 
nation of spatial partitioning, model parti- 
tioning, and frame coherence (an assump- 
tion that motion is generally smooth and 
changes per frame are small in a given 
scene), optimizations can be made to 
reduce overall computational time in cal- 
culating pair-wise collisions between the 
various types of polyhedra. Each section 
presents several partitioning methods and 
provides a case study regarding their per- 
formance, along with a test bed of com- 
plex objects to help highlight the perform- 
ance differences. 

SOLID has been under development for 
the past seven years, and chapter six pro- 
vides the goals, an overview, design deci- 
sions, and restrictions of the library. In 
fact, the material presented in the book is 
implemented as the SOLID library. The 
provided SOLID source code helps con- 
textualize the algorithms and discussion 
presented in the text. Finally, the last 
chapter describes the current limitations of 
collision detection and considers future 
research areas where further improvement 
might occur. 

Overall, the book does an excellent job 
presenting the challenges and necessary 
considerations when designing a collision 
detection system but not in a manner that 
is approachable by everyone. Developers 
capable of appreciating the mathematics 
and theory will benefit from van den 
Bergen's description of his insights and 
experience. One drawback, though, is 
that his presentation is tailored toward 
the SOLID API implementation, rather 
than being a complete look at the prob- 
lem in general. 

^ j^^f I Collision Detection in Interactive 
3D Environments \ Morgan Kaufmann 
w/ww.mkp.com 

Jeremy works for Rockstar San Diego. 
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TALKING TO PEOPLE WHO MAKE A DIFFERENCE | Jamil mole din a 



Hard- Boiled Developer 

Luxof lux's Peter Morawiec on bringing classic story genres to life 



Peter Morawiec makes crime play. 



As co-founder of Luxoflux, Peter 
Morawiec has heard it all 
before. Having broadened the 
vehicular combat genre with 
games like Vigilante 8 and 
Star Wars: Demolition, he's used to fielding 
comparisons to pioneering titles. Well, it was 
deja vu all over again, as gamers, marketers, 
and, yes, even journalists made connections 
between Luxoflux's recent True Crime: The 
Streets of L.A. and the seminal sandbox title 
Grand Theft Auto IIL This time out, the 
story took an unexpected turn when author 
Robert Crais accused the game's developers of 
infringing on his novels. When Luxoflux and 
publisher Activision showed him the game, he 
saw how distinct it was from his work, and 
dropped the suit. Although this added an unwelcome layer of 
drama to the release of True Crime, it validated Morawiec's 
dogged pursuit of innovation. As project/design lead on True 
Crime, Peter delivered that innovation by integrating the story 
tightly into the game. 

GD: What factors led you to connect True Crime's gameplay so 
dependently to story? 

PM: I'm a big movie and fiction buff, so True Crime was 
always envisioned to be a story-driven game. I was hoping we 
could create something akin to a videogame incarnation of an 
action film, where the story and gameplay blend into one 
another seamlessly (subject to load time limitations). We used 
very short, palatable cinematics to progress the story, while 
placing the action segments in the player's hands. 

Simultaneously, I wanted to achieve a sort of hybrid active- 
passive experience, where the entertainment goes on no matter 
how badly the player does, allowing even a total newbie to 
fumble his or her way through an entire storyline, without 
repeating missions or getting stuck. In a passive medium such 
as a movie, whenever the hero hits a low point mid-film, the 
story doesn't restart; rather, the hero recovers or finds another 
way to go on. This is especially true in detective stories, where 
the protagonist tends to encounter a few dead ends before 
eventually connecting the dots. However, many gamers will 
instinctively want to replay a failed mission, so the jury's still 
out on this particular feature. 
GD: What is your writing process? 

PM: I prefer to arrive at a condensed story outline first — the 
general theme, the hero, the villain, their motivations, the cli- 
max, the introduction event, key branch points, some loca- 




tions, and story twists. At this stage, I try not 
to concern myself with gameplay issues much, 
but I never discard those considerations com- 
pletely either. The next step involves detailing 
out the story and breaking it down into indi- 
vidual cinematic and gameplay components. 
Games tend to be considerably longer than 
films and most time is "action time," so 
you've got to stretch the script and proliferate 
it with gameplay mechanics pertinent to your 
game. Unlike a traditional movie script, each 
conversation is described merely in terms of 
its content and tone, not the actual final dia- 
logue, which comes last. We hire professional 
writers to assist us with tuning the script and 
developing all dialogue. One of the lessons of 
True Crime is the need to write matching 
VO for both cinematics and gameplay — the game is very 
campy throughout, but it also features several darker 
moments, so the main character's generic one-liners often end 
up out of synch with the mood of the story. 

GD: Given True Crime's connection to hard-boiled detective sto- 
ries, how important is it for games to explore narrative genres? 

PM: As the videogame market matures, I believe it's natural 
for story-driven games to be crafted within established narra- 
tive genres. With the age of today's average gamer pegged at 
something like 29, the audience welcomes a greater thematic 
variety as well as deeper and more mature storylines. I believe 
that people will instinctively want to play the same types of 
genres they like to watch or read. As a matter of fact, we've 
already seen a number of successful games dubbed as horror, 
film noir. Hong Kong action, and so forth. 

GD: In light of Grand Thef Auto II Ts notoriety, is it better to 
market a crime game as a GTA-killer or as an original experience? 

PM: As a game maker, I'd clearly prefer the latter. However, 
from a sales standpoint, I'd imagine it is always beneficial to 
make bold claims (so long you can back them up). Either way, 
the challenge lies in managing consumers' expectations, which 
is an extremely tricky thing. 

GD: In retrospect, what steps can a writer and a project lead 
take to head off infringement claims before lawsuits are filed? 

PM: Games are big business, so as long as there are willing 
lawyers, there will be lawsuits. The best thing to do is to per- 
form plenty of legal due diligence before you ship. 
GD: What games are you playing now? 
PM: Call of Duty, Shrek 2 (in development internally), 
and eagerly awaiting Half-Life 2. 
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INNER PRODUCT 



Jonathan blow 



Designing the Language 
Lerp: Part 3 



Lately, I've been developing a programming lan- 
guage called Lerp. Lerp is an imperative language 
with some declarative extensions for data han- 
dling. The declarative statements are based on 
predicate logic ("Predicate Logic," December 
2003), a simple way of reasoning with facts well known in the 
AI community. 

In the past few articles I've shown how predicate logic 
expressions can be used to manipulate data in concise and 
powerful ways. However, the traditional handling of predicate 
expressions, in languages like Prolog, has some problems that 
need to be addressed. Prolog was never adopted for wide- 
spread use; I believe this is partially due to some software- 
engineering shortcomings that Prolog proponents were slow 
to acknowledge and fix. 

Software-Engineering Problems 

A language with good software-engineering properties helps 
you keep a program from becoming too chaotic as it 
grows; such a language supports software-development pat- 
terns that result in fewer bugs and makes it easy to find bugs 
when they do happen. As an example, C++ performs type 
checking at compile time and link time, so many common 
errors (like passing the wrong argument to a procedure) are 
caught and fixed before you ever run the program. On the 
other hand, LISP doesn't have static type checking, so you can 
only find type errors at runtime. Those errors might lurk for a 
long time, if they're in code paths that are infrequently exer- 
cised. So C++ provides a definite advantage over LISP in 
terms of getting real work done. 

On the whole, predicate logic is an error-prone method of 
expression. Traditionally, there's not much in the way of com- 
pile-time error-checking. The speed of your program and its cor- 
rectness depend drastically on small variations in the way the 
predicates are written. I'll illustrate this with some examples. 




FIGURE 1 : We represent this set of nodes arranged in a tree in predi- 
cate logic assertions as ['parent a b], ['parent b p], ['parent c p], 
['parent d c], ['parent e c]. 

Suppose you have some objects arranged in a tree; there is a 
parent relationship that links objects together (Figure 1). We 
want to ask whether one object is an ancestor of another, in 
other words, whether it can be reached by traversing some 
number of parent links. Using Lerp syntax, we would define 
the ancestor predicate like this: 

['ancestor ?x ?a] <- ['parent ?x ?a]; 

['ancestor ?x ?a] <- ['parent ?x ?p] & ['ancestor ?p ?a]; 
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The first line says a is an ancestor of x if a is the parent of x. performance and correctness, we end up spending most of our 
The second Hne says a is an ancestor of x if x has some parent p, time thinking about the course of action this solver algorithm 
and if a is an ancestor of p. The second line performs recursion will take to put our facts together, when we're supposed to be 
and the first line handles the i / / / ' r thinking about just the facts 

simplest case; the two lines 1^6 eHCI Up SpenCling tTlOSt Of OUf themselves, 

together provide a complete ^ ^ ^ For example, Prolog's 

definition of ancestor. 1 11716 t til liking QbOUt ttlS CO UTS 6 Of solver will consider the facts 

One of the nice aspects of one by one in the order you 

predicate logic is its declara- QC^lQf} ttlQ SOlVBf 0,1^0 flthfTl Will tdliB ^^^^ ^^^"^ (for details, see 
tive structure. In theory, you ^ the sources listed under For 

just state the facts, and the ^^^^^ to Dutour facts togettier, °" rf 

runtime system figures out i / O IV), so the ancestor relation 

the answers to your queries / / J j. L J.L ' I ' as written above would be 

based on the stated facts. ^VHeO WB SUppOSeCl tO 06 thinking an efficient way to pro- 
However, in reality, it's just , . j_ j_L £ j. j.L ! gram. But suppose you 

not that simple, because QDOUt JUSt the JQCtS themSeiVeS. switch the order of the 

facts can't get up and solve statements like this: 

problems by themselves. In 

predicate logic systems, there's a solver algorithm that tries to ['ancestor ?x ?a] <- ['parent ?x ?p] & ['ancestor ?p ?a]; 

put facts together to eliminate unknowns. The problem with ['ancestor ?x ?a] <- ['parent ?x ?a]; 
traditional predicate logic systems is that, due to concerns over 
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Now you have a program that is extremely inefficient. It 
will always perform a recursive search first, climbing all the 
way to the root of the tree and whizzing right past the answer, 
only finding the answer as it backtracks. 

The situation can get worse if, for instance, you switch the 
order of the conjunction in the first rule: 



['ancestor ?x 
['ancestor ?x 



?a] <- ['ancestor ?p ?a] & ['parent ?x ?p]; 
?a] <- ['parent ?x ?a]; 



Now the solver will just loop infinitely. An attempt to 
answer any ancestor question will cause the solver to immedi- 
ately pose another ancestor question. As long as our examples 
remain this simple, we can work around them without too 
much strife. Maybe we can add some compile-time checking 
to spot simple loops like the one above. But, as with any lan- 
guage, the situation gets murkier when the program gets big- 
ger, due to additional relations that reference one another 
recursively in various ways. As the program grows, we must 
work harder to manage the solver's data processing. Writing a 
large-scale software project like this will not be as much 
about logic as one would hope. 

To top it all off, there are a lot of places this kind of solver 
just can't reach. Imagine we want to make the solver navigate 



FIGURE 2: A graph that con- 
tains cycles will cause 
problems for a Prolog 
solver. In this scheme, each 
arc between the nodes rep- 
resents an assertion of the 
form of ['neighbor ?a ?b]. To 
ask whether a path exists 
between rooms, we can 
define a primitive connected 
that traverses these neigh- 
bor facts. 

an arbitrary graph 
(Figure 2). Let's say we 
have a fact, neighbor, 
which tells us whether 
two nodes have an arc 
between them, and we 
want to define a relation, 
connected, which tells us 
whether two nodes are 
some number of neigh- 
bor-steps away. Well, a 
Prolog solver will just go 
into an infinite loop on 
this problem, period. To 
fix this, we need to add 
lots of extra data and 
relations to manage the solver's progress, and we end up doing 
the same kind of work we must do in imperative language, 
except in a more Byzantine manner. Recent variants of Prolog, 
and other logic programming languages, apply numerous band- 
aid approaches to this problem, but I have not seen one that 
solves the problem to my satisfaction. 

Flow control is implicit in such declarative languages, so it's 
very hard to manage if you need to actually steer the process. 
This is not nearly as nice as in an imperative language, where 
the programs are lists of statements that say, "Do this, then 
this, then this." 

Control the Solver 

This straightforwardness of imperative languages is why I 
designed the core of Lerp to be imperative, but so far 
there's an extreme asymmetry in the language design. The 
imperative part can scale, with reasonable confidence that the 
program will do what you hope. The logic part, though, is 
only useful for simple tasks; as facts in the logic system 
become more complicated, the program will probably start 
running slowly or loop infinitely — who knows? I don't feel I 
can produce reliable programs with acceptable efficiency 
when things get large on the logic side. 
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Maybe that's not so bad — if the imperative side is good 
enough, maybe the language philosophy should be that logic is 
only used for simple things. Certainly, the matrix and vector 
examples previously shown ("Designing the Language Lerp: Part 
2," February 2004) are interesting and useful, and we could just 
accept those (along with the carrying example) as the limit of 
what the logic in Lerp will do. But I want to push it further. 

Simplified Ancestor 

Throughout the language design process, I have been keep- 
ing in mind the most effective features from other lan- 
guages, like Perl, and looking for opportunities where they 
can be gainfully employed. In this case, I found a way to 
reframe Perl's regular expression handling. Let's go back and 
look at that definition of ancestor: 

['ancestor ?x ?a] <- ['parent ?x ?a]; 

['ancestor ?x ?a] <- ['parent ?x ?p] & ['ancestor ?p ?a]; 

What we're trying to say here is, "An ancestor is anyone you 



can reach by following a parent relation one or more times." 
This is interesting because "one or more times" is a common, 
primitive concept in regular expression-pattern matching: it's 
denoted with a +. In fact, if we treat parent as a single symbol, 
then the idea "one or more parent relations" would just be 
written in regexp form, as parent+. With that in mind, we can 
develop an alternate syntax where ancestor is defined like this: 

['ancestor ?x ?a] <- /{ ?x 'parent+ ?a }; 

This definition treats the database facts of Figure 1 like a 
graph. The /{} are just syntactic markers, saying that the braces 
contain instructions about how to walk the graph. This particu- 
lar graph-walking expression says, "Start at x, then follow one 
or more parent arcs until you arrive at a." The symbol parent is 
still assumed to be a binary operator like in the previous defini- 
tion. Think of { ?x 'parent+ ?a} as expanding as follows: 

['parent ?x ?tmp_l] & ['parent ?tmp_l ?tmp_2] & ... & ['parent 
?tmp_n ?a] . 
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If it helps reduce confusion, we can reformat the parent facts 
in the database so the identifier 'parent is infix rather than pre- 
fix, so the facts look like [nodel 'parent node6] instead of ['par- 
ent nodel node6]. This is just a cosmetic change, and clearly we 
can do a graph-walk among facts stored in either format. 

Complex Graph Walks 

We can compose longer graph-walking expressions. 
Suppose we want to find whether x and y have a com- 
mon parent. There are several ways to form this query. We 
could say /{ ?x 'parent+ ?p } & /{ ?y 'parent+ ?p }, meaning, 
"Is there some common p reachable by parent-steps from 
both X and y?" Or we define the relation child as ['child ?a 
?b] <- ['parent ?b ?a]; then we can string together one expres- 
sion that looks like this: /{ ?x 'parent+ ?p 'child+ ?y }. 

That may be easier to think about, since it talks about one 
continuous path, from x up to p down to y. But the point of 
child is just to define a transition that goes in the direction 
opposite of parent. Requiring a separate definition for that is a 
little cumbersome; instead, we can add some notation to the 
graph-walking expressions to say, "Switch the order of the 
arguments before searching for this fact in the database." 
Let's use the ~ character for this, with the little wave symbol- 
izing the swapping of two things. Then the query becomes /{ 
?x 'parent+ ?p ~'parent+ ?y }; whether you prefer this is a mat- 
ter of taste, but it does make for a simpler program. Another 
way to think of ~ is that it means, "Go backward along this 
graph edge instead of forward." 

Let's apply this to a concrete game situation. Suppose 
you're making a fantasy game, and a dragon has just breathed 
on a player, whom we will call victim. We want to apply dam- 
age.amount points of damage to everything flammable the play- 
er is carrying. We know an object is flammable if it has a 
member variable flammable set to true. 

The catch is, we need to search for items that are not in the 
player's top-level inventory. If the victim is carrying a bag, and 
there's a scroll in the bag, then we will have facts ['carrying 
victim bag] and ['carrying bag scroll], but probably no ['carry- 
ing victim scroll], since such deep linking would make data 
handling cumbersome and expensive. So when it comes time 
to burn the stuff, we need to perform a recursive search 
through the player's inventory to make sure we find every- 
thing. Supposing we have some function apply.damage, we can 
invoke it on all relevant entities like this: 



value we reach. If that member variable doesn't exist or is 
false, the traversal fails for that particular path and returns 
nothing; otherwise, it returns the node in the ?? slot. Recall 
that the each as a function argument causes apply, damage to be 
called once for each entity that satisfies the query. 

That's pretty good. It's different from what you'd do in 
many other languages, and it's certainly simpler. You can 
imagine ways of adding further regexp syntax to handle fire- 
proof containers. It works out to be pretty simple. In fact 
most of the convenient features of regular expression syntax 
can be adopted directly into this graph-walking scheme 
(parentheses to join patterns into larger groups, and so forth). 

What this Notation Does 

This graph-walking syntax helps us phrase queries in ways 
that are more straightforward and compact than with tra- 
ditional predicate logic. But it also does something more 
important — it gives us a way to avoid the recursion and termi- 
nation pitfalls. When evaluating a term like carrying+, the 
graph-walking engine can just assume some things that are 
difficult to deduce in a general predicate logic environment. 

Going back to the non-hierarchical situation of Figure 2, a 
graph walker can easily solve the query with no risk of infi- 
nite looping, without requiring the programmer to add ancil- 
lary data. It can just mark the nodes it has visited and never 
try them again, since there's no reason to visit a node twice 
when evaluating a pattern option like +. This is valuable, since 
it widens the scope of queries that the programmer can make 
while feeling confident and safe. This month's sample code 
(available at www.gdmag.com) implements the examples dis- 
cussed here, and some others. 

Relation to SNePS 

The regular expression query syntax treats a predicate logic 
database as a series of nodes connected by arcs. 
Interestingly, there are some systems developed in the AI 
world centered around this idea of graph traversal. The most 
prominent one is SNePS (see For More Information), consid- 
ered by some to be a helpful tool for knowledge representa- 
tion in natural language processing. The semantics of SNePS 
are not exactly like what we have discussed here, though there 
are some interesting similarities. 



apply_damage(damage_amount, each /{ victim 'carrying+ ?? 
.flammable }); 

In this graph-walking expression, the carrying+ finds all the 
entities starting from victim, the ?? indicates the node in that 
slot should be the return value of the expression and the 
.flammable looks up the member variable flammable on whatever 
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Subdivide and Conquer 
Part 2: Practicalities 



This month we're going to return to the discussion 
of subdivision modeUng we started previously 
(Artist's View, January 2004). Since the theoretical 
part is out of the way, we can now focus on some 
practical rules for dealing with subdivisions. 
First, let's quickly recap the basics from our earlier discus- 
sion. A subdivision surface is made by recursively refining a 
polygon mesh. The topology of the original mesh determines 
the quality of the smoothing. Connected mesh edges that pass 
through the four-way intersections in the control mesh (edge 
loops) create smooth B-splines on the subdivision surface. 
Conversely, vertices that have more or less than four incoming 
edges (pole points) terminate edge loops, interrupting the flow 
of the surface and introducing a cusp on the surface right 
under the pole. Faces with more or less than four sides also 
create smoothing glitches when they are refined (extraordi- 
nary points), although in a typical game model these aren't 
too serious. 

For these reasons, the ideal subdivision model is built from 
a grid of quads. Since all of the faces are four-sided, they sub- 
divide smoothly. More important, since all of the internal 
intersections in a quad grid are four-way, every series of con- 
nected edges in the mesh is a smooth spline, so it's easy to 
build models with smoothly curved surfaces. Note that a mesh 
is only a quad grid if all of its vertices (except those on the 
outer borders) have exactly four incoming edges. Many mesh- 
es that are made entirely of quads don't qualify as quad grids 
(Figure 1). 




FIGURE 1. An all-quad mesh can still have pole points, where more or 
less than four edges meet. Note the discontinuity of the splines on the 
surface of the subdivision sphere. 

describes the subdivision workflow as "volume, surface, 
detail." This top-down process stresses the importance of 
working from the largest aspects of the model to the smallest. 
This is usually a good practice in any case. With subdivisions. 



Advice for the Left Brain 

Because of the stress subdivision modeling places on mesh 
topology, it tends to require more forethought than tradi- 
tional polygon crunching. Bay Raitt, who did the the subdivi- 
sion models of Gollum in the Lord of the Rings movies. 
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it's especially important, since an accidental pole point can 
distort the sweep of a large contour. Thus, in my capacity as a 
conscientious columnist, I am obliged to make a public pitch 
for careful planning. 

In any case, subdivision tools implicitly favor a top-down 
process. Most major packages implement Hierarchical 
Subdivision Surfaces (HSDS), allowing you to work directly 
on vertices created by different iterations of the subdivision 
process. HSDS is invaluable for localizing details; the wrinkles 
in a character's forehead, for example, are best done locally at 
a higher subdivision level than the rest of the model. Without 
the ability to drill down in the subdivision hierarchy, the 
detail areas would have to be carefully stitched to the lower- 
resolution regions or they would propagate unneeded control 
points to the simpler areas in the way NURBS models often 
do. Moreover, HSDS details will move with their parent sur- 
faces if the base control mesh is changed, so large scale edits 
can be made without disturbing completed detail work. 

Unfortunately HSDS has important limitations. Most 
importantly, the topology of the hierarchical subdivisions is 
determined by the topology of the original control mesh. So, 
for example, you can't add a wrinkle line across a forehead in 
a higher subdivision level unless the edges flow in the right 
direction on the base level (Figure 2). Moreover, in most 




FIGURE 2. HSDS's lower levels derive their topology from the base 
mesh, which could be a limitation in some cases. 
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implementations, changes to the base topology can confuse 
the detail layers, leading to unpredictable migrations of details 
as the vertex indices change. Most important, HSDS doesn't 
change the basic behavior of subdivisions and the need for 
clean topology at the highest level. Thus HSDS is ideal for 
organized modelers, but offers relatively little to intuitive, 
improvisational, or just plain sloppy artists. 

Back to the Future 

NURBS are often a good starting point for a well-planned 
subdivision model. Beginning your model with NURBS is 
also a good way to include a strong foundation of quad grids, 
since NURBS patches are fundamentally quad-based. More 
important, though, starting the model with NURBS helps to 
separate the volume stage of modeling from the surface stage. 
NURBS patches can be rebuilt on the fly to almost any level 
of detail. With subdivisions, on the other hand, adding or 
removing control points always involves some alteration in 
the final form. Roughing out your main forms in NURBS 
allows you to concentrate on the model without worrying too 
much about the distribution of the control mesh. Once the 
shapes look right, you can go back and assign density where it 
is needed by cutting up or rebuilding the patches. 




FIGURE 3. Generally it's a good idea to define major forms in 
NURBS before starting a subdivision model. 
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FIGURE 4. Irying lo iix me poie point ana n-gon lupper lerg sinnply 
moves the problem around. 

Integrating NURBS into a subdivision model is fairly sim- 
ple. You simply convert your NURBS into polygons, which 
are then stitched together to serve as the basis of a subdivi- 
sion-control cage. Generally, the most efficient way is to 
model only the important forms, leaving the connecting areas 
for the subdivision model (Figure 3). Subdivisions handle 
oddly-shaped, arbitrary blends more easily than NURBS do, 
so there's no need to build NURBS shapes — such as boundary 
surfaces, trim-blends, and multi-sided fillets — that are basical- 
ly there to serve as fillers. Here's a good rule of thumb: any- 
thing that requires a lot of thought in the NURBS stage is 
probably better fixed in the subdivision stage. The only really 
finicky task worth doing in NURBS is matching up the 
isoparms of adjacent patches, which will reduce the time 
required to stitch together the subdivision cage. 

The one important trick is to convert the control cage of 
the NURBS model rather than the final limit surface. In other 
words, you want to copy the NURBS control cage into your 
subdivision model. Maya offers an option to do this directly; 
however, in Max or XSI, you'll need a script that builds a 
polygon mesh out of NURBS CVs. Unfortunately there are 
subtle but important differences in the underlying math (see 
Artist's View, January 2004), so conversion between NURBS 
and subdivisions will not be perfect. For most purposes, how- 




are more predictable than those with an odd number (right). 

ever, the conversion is adequate without additional tweaks. 
You can improve conversion accuracy by increasing the num- 
ber of NURBS isoparms before conversion. 

Now for the Right Brain 

Now, it's time to return to the messiness of the real world. 
Most of us are too busy thinking about our subject mat- 
ter to worry about the topology every time we touch a mesh. 
Moreover, we often tend to obsess over local details that crop 
up, because the little details often tell us so much about the 
way the overall model will evolve. 

The result is that most of us — especially those who learned 
the trade as low-polygon modelers — add or subdivide faces 
more or less at random when trying to capture an elusive detail 
or suggestive contour. It takes a lot of discipline to follow a 
strict top-down methodology. 

Therefore, it's time to take a look at the alternative to plan- 
ning: cleanup. Artistic issues aside, the ordinary give-and-take 
of roughing out a mesh almost always leaves behind a trail of 
accidental pole points and unintended w-gons, which need to 
get polished off before the model is truly ready for prime 
time. Trying to eliminate nasty little shading glitches or con- 
tours that refuse to stay put can consume a lot of time, even 
when a model appears to be nearly done. So let's look at some 
practical aspects of fixing an existing subdivision cage for 
optimum results. 

For game modelers, the key task is really two-fold: deciding 
which vertices have to be fixed and which faces have to be 
quadrangulated. In theory you could build a complete quad 
grid mesh with hordes of tiny polygons taking the place of 
irregular intersections and faces; however, the practical prob- 
lems with trying to manage such a heavy mesh generally out- 
weigh the benefits, at least in game applications. High-resolu- 
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FIGURE 6. Here are some examples of possible (blue) and impossible 
(red) quadrangulation when adding adjacent faces. 

tion modeling for films or real-world CAD applications may 
demand complete topological purity. For games (even game 
cinematics), it's easier and more realistic to accept some poles 
and w-gons as necessary evils. 

Sweeping Under the Carpet 

Most of the time, moving topological problems into incon- 
spicuous places is an adequate alternative to eliminating 
them. Usually, fixing a topology problem in one place causes a 
new one to crop up nearby (Figure 4). By far, the worst part 
of trying to regularize a subdivision mesh is the agony of 
spending half an hour tweaking a problem area only to realize 
you have reshaped the mesh back to its original configuration. 
Settling for simply hiding the glitches instead of eliminating 
them turns the frustrating task of chasing an error into a use- 
ful tactic. For this reason, keep an eye out for transitional 
areas that are obscure or don't have strong forms where you 
can offload tricky connectivity problems. 

In other cases, the tradeoff is topological rather than spa- 
tial. Not all flaws are equally serious, so choose the lesser 
ones. For example, eliminating a pole point frequently means 
creating an w-gon, or vice versa. In general, if you are forced 
to choose between an n-gon and a pole, accept the n-gon, 
since a pole has two bad side effects (a shading glitch at the 
extraordinary point and a break in the flow of the surface 
spline) whereas the ^-gon has only one. 

It's also worth remembering that pole points with an even 
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number of incoming edges are also less problematic than 
those with odd numbers. Although an even-sided pole point 
still creates an extraordinary-point shading glitch, the surface 
flow under an even-sided pole is smoothly continuous along 
the opposite incoming edges (Figure 5). Odd-sided poles, by 
contrast, produce a clear discontinuity for all the incoming 
edges. The one exception to the even-odd rule is that vertices 
with only two incoming edges (unless they are on an open 
border of the mesh) are always a bad idea, since they usually 
produce very noticeable divots in the subdivision surface. 

Quad Squad 

Because quads produce the cleanest and most predictable 
subdivisions, you always want to use them instead of the 
w-gons if you can. w-gons should be used only as connective 
tissues in areas without important structure or definition. 
When you're trying to grid up an existing irregular mesh, 
you'll find that any n-gon with an even number of sides can 
always be divided into quads without adding any vertices. 
Conversely w-gons with odd numbers of sides can only be 
quadded by splitting one of their original edges. Usually this 
will involve extending the split until you reach an acceptable 
pole point or an open edge of the mesh. When applying the 
even-odd rule for a group of faces, remember to subtract two 
from the total edge count for each shared edge. So, for exam- 
ple, a triangle adds one edge to a quad (4 + 3 - 2) if it is con- 
nected by one edge, but actually subtracts one if it is connect- 
ed to two edges. Thus, you can't make quads by deleting the 
edge between a quad and a triangle (4 + 3-2 = 5), but you 
could do so by adding a quad and two triangles (4 + 3 + 3-4 
= 6) (Figure 6). 

Survival of the Fittest 

Subdivisions are still in their infancy. Although they are a 
great step forward, they certainly don't represent the end 
of the line in the evolution of modeling tools. Most subdivi- 
sion modelers are really just glorified polygon tools — they're 
great for quickly hacking around, but they don't give the 
artist a whole lot of leverage. Recently a lot of development 
energy has gone into useful but basically cosmetic improve- 
ments, like isoline displays or edge-loop selection tools. 
What's really needed, though, is better integration of more 
sophisticated functions. Tangency projection, freeform fillets, 
radius fillets, and — most importantly — trims would all 
tremendously upgrade subdivision modeling. So would native 
subdivision-support for tools like bi-rail lofts. Even mathe- 
matically correct NURBS-to-subdivision conversion would be 
a big step forward. If your software rep comes around the 
office asking what you want to see in the next version of your 
package, don't be shy — speak up! '0' 
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t i m r o c h e 



Laying the Smackdown 
on Voice Recording 



As an audio engineer at 
World Wrestling Enter- 
tainment, I record the voic- 
es of our on-air talent and 
wrestlers. There is an art 
to recording the human voice, capturing 
all its nuances and timbre, which requires 
the right mics, gear, and professional 
experience. This is especially true for 
videogames because others will rely on the 
quality of your recordings at a later stage 
of game development, and you must be 
right on the money. 

No gain, no game. I record sessions flat; 
no EQ, no compression, and no DSP (dig- 
ital signal processing). Our audio chain is 
quite pure: from the mic (Neumann M 
149 Tube, Sennheisser HMD 25-1 headset 
mic) to the mic pre (Summit Audio MPE- 
200) to the console (Euphonix System 5 
digital broadcast console), out of the con- 
sole digital (AES) to a Sony PCM 7040 
DAT. To have something to work with, it's 
critical to have a good gain structure, and 
a solid, strong signal. 

For our latest game, WWE Smack- 
down! Here Comes the Pain, I decided 
to go with the Sennheiser HMD 25-1 
headset mics because these are the mics 
that are used for the broadcast of 
Smackdown and I wanted the commen- 
tary to sound authentic, not done after the 
fact in audio post. This goes along with 
my theory of recording in general: 
Capture good sound from the original 
source and you won't need to do much to 
it to make it sound great. This way, when 
it's time to mix, half the battle of getting 
accurate sound is already taken care of. 

In your face. Recording WWE 
wrestlers poses some unique challenges. 
Given the physicial and psychological 
demands on these athletes, they are gen- 
erally very intense people who have no 
time to waste. I have to be conscious of 
my gain structure. Too hot a signal will 
cause over modulation, which in the dig- 
ital world is unforgiving and sounds 
awful. What I like to do is place a wind- 
screen approximately 10 inches in front 




Balancing gain and personality: recording 
WWE wrestler Mick Foley and on-air 
announcer Jonathan "The Coach" Coachman 



of the mic capsule. People by instinct, 
tend to get real close to a windscreen, so 
by creating space (from the capsule to 
the windscreen) you effectively create a 
more favorable gain structure. Imagine if 
Stone Cold Steve Austin were asked to 
record some voice elements. He would 
probably be intense, just like he is in the 
ring. But, by having that space, I can 
control and adjust my mic gain (on the 
preamp) seamlessly, without wasting 
precious time, which is paramount. 

Keep it clean. Preparing your talent is 
important because they need to know 
what is expected of them. For instance, I 
explain to the wrestlers how this is going 
to be used in a game, and that their 
words should be clear and deliberate. 
Usually, there are hundreds of phrases, 
exclamations that need to be "clean." 
Every wrestling move sound, grunt, and 
spoken name needs to be isolated. For 
example, if The Rock pounds Stone Cold 
Steve Austin with the "People's Elbow," 
then the sound of the interaction. Stone 
Cold's reaction, and the announcer's 
commentary need to be recorded sepa- 



rately, so they can be used in varying 
combinations in real time during game 
play with perfect clarity. 

No conversions below the belt. Other 
elements to consider are sample rate and 
bit rate. Our audio post rooms are out- 
fitted with Fairlight MFX 48 digital 
workstations. We are running these sys- 
tems at 48KHz/24-bit. The Fairlights 
work in tandem with the Euphonix 
System 5 console seamlessly. The 
Euphonix utilizes MADI technology so 
once the audio stream is converted to 
digital (AES to MADI), we can output 
to many different (AES) sources. For 
gaming sessions the result is a 44.1KHz 
16-bit R-DAT. I output AES to a Sony 
PCM 7040 so there's no sample rate 
conversions to deal with. 

Sample rate conversions can get a bit 
dicey. Remember digital audio is a binary 
representation of an analog sound. The 
more conversions you introduce into your 
bit stream, the further away you are from 
the original analog sound. Consider the 
audible difference between a WAV file 
and a compressed MPS of the same 
source. The same holds true for sample 
rate conversions. The more pristine the 
signal, the better it will sound at game 
time. The ideal is for a developer to be 
able to plug this audio directly into the 
game without conversions. 

Before you step out of the ring. To elimi- 
nate "fix it in the mix" scenarios, I apply 
some knowledge learned from analog 
audio engineering. One trick is to pot up 
all your faders to zero, then use the mic 
trims to get a good strong level. The key 
is to actually listen to the sound you're 
getting. This may sound simple, but it's 
easy to overlook, and can make or break 
your in-game audio. 




TIM ROCHE I Tim is the audio post engineer for World Wresling 
Entertainment, working on WWE's TV programming and games such 
as WWE Smackdown! Here Comes the Pain, WWE Smack- 
down! Shut Your Mouth, and WWF Smackdown! Just Bring 
It. He also worked on a wide range of TV shows and videos. 
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BETTER BY DESIGN 



n o a h f a I s t e i n 



Beyond Sntertainment? 



The late media analyst Mar- 
shall McLuhan once said, 
"Those who make a distinc- 
tion between education and 
entertainment don't know 
the first thing about either. " 

When I first heard the quote many 
years ago, I thought he was overstating 
the case: there is a lot of entertainment 
that has nothing to do with education, 
and much of education is far from enter- 
taining. But the more I think about it, 
particularly about the game design work 
I've done that's intended for teaching or 
training, the more truth I see in his state- 
ment and its pertinence to games. Games 
are teaching exercises: you play them as 
long as there is something new to learn, 
whether it's the controls of an X-Wing 
fighter, the right kung-fu sequence to dis- 
able an AI opponent, or the crystal rota- 
tion method required to finish a level. 
On the academic side, the best teachers 
I've had are those who made learning fun 
and turned the process into a game, a 
competition, or a journey of discovery. 

The 2004 Game Developers Confer- 
ence includes for the first time a Serious 
Games Summit focusing on games with 
training or educational goals. I've experi- 
enced the growth and diversity of this 
field firsthand, designing games that 
encourage good nutrition, help kids with 
cancer cope with their treatment regi- 
mens, or help Shell employees under- 
stand what their colleagues in explor- 
ation and production go through to find 
and collect oil and natural gas. The well- 
publicized area of educational games 
based on academic subjects is just a sub- 
set of this branch of game development. 
The Serious Games Summit allows the 
less-publicized and burgeoning areas that 
focus on adult learning and training to 
come to the forefront. 

Inspired by the upcoming summit, I 
invited two experts in this field — Ben 
Sawyer, cofounder of Digital Mill and 
designer of Virtual U, and Marc Prensky, 
founder of GameslTrain and author of 



If Rogue Squadron can teach you to fly an X- 
Wing, can games teach you to eat right? 

Digital Game-Based Learning (McGraw- 
Hill, 2000) — to suggest some relevant 
game design rules. They provided enough 
material for several articles. Here's a 
summary of some of their key points. 

Ben Sawyer counsels developers to 
focus on a mission, a desired outcome 
that transcends the usual industry goal 
of selling lots of copies. This focus 
reminds us the game "is usually a subset 
of a larger project with greater goals for 
the client." He also points out that, 
with this sort of game, we are designing 
for more than just the player and must 
address the needs of the instructors, 
teachers, or trainers who might want to 
customize it and monitor the partici- 
pants' progress. 

Finally, he suggests we remember to 
apply the numerous strengths of our 
industry and not simply the most obvious 
seUing point that "good games are fun." 
For example, games can be easily cus- 
tomized by teachers and trainers and can 
adapt to the individual. At the same 



time, game developers are experts in the 
practical appHcation of AI, 3D graphics, 
and simulation. Ben believes we need to 
demonstrate these comparative advan- 
tages to potential serious game sponsors 
to promote the use of game industry 
techniques in training. 

Marc Prensky shares my uneasiness 
about the term "Serious Games," since 
this can erroneously imply that educa- 
tional games are not fun or that tradi- 
tional games with no purpose other than 
entertainment are somehow not serious 
business. Making a game fun is a great 
challenge in itself; providing game con- 
tent that teaches a player something real 
is even harder. His first rule: "Content is 
important, but fun has to trump con- 
tent — don't suck the fun out!" He sug- 
gests posing a few questions to validate 
the effectiveness of these learning games: 
"Is this game fun enough that someone 
who is not in its target audience would 
want to play it (and would learn from 
it)? Do people using it think of them- 
selves as players rather than students or 
trainees? Is the experience addictive? 
Does it encourage reflection about what 
it teaches?" 

Both Sawyer and Prensky discuss at 
length ways to convince potential clients 
that games and game industry tech- 
niques have merits as educational and 
training tools. My experience suggests 
that as people who grew up with com- 
puter games mature and move into 
authoritative positions in traditional 
industries, we'll see a huge increase in 
the acceptance of games as a fun and 
effective way to train people. I'll follow 
up in a future column with lessons 
learned at the summit. 




NOAH FALSTEIN I Noah is a 24-year veteran of the game 
industry. His web site, www.theinspiracy.com, has a description of 
The 400 Project, the basis for these columns. Also at that site is a 
list of the game design rules collected so far, and tips on how to 
use them. You can e-mail Noah at nfalstein@gdmag.com. 
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SCHEDULING 



m i ch a e I s a I a d i n o 



The Secret's in the 

Schedule 

Bending The Mythical Man-Month 




he Mythical Man-Month 
is a seminal work on not 
just software engineering 
but the psychology of 
human interaction inside 
a team environment. 
Nearly everyone in our industry is famil- 
iar with the name of the book and most 
have a cursory understanding of its cen- 
tral tenets. However, significantly fewer 
people have ever actually read the book 
or have a deep understanding of it 
beyond some well-known quotes that 
have become platitudes. This lack of 
deep understanding leads to two prob- 
lems. First, people don't prevent actions 
that go against the very pretense of the 
book, which means they make mistakes 
that were identified as mistakes nearly 
30 years ago. The second problem is 
people rely on an overly simplified 
understanding of the book and therefore 
are unable to conceive how its funda- 
mental rules can be bent and twisted to 
allow that which seems impossible. 

Obviously I recommend everyone put 
this book in his or her personal reading 
queue and get to it soon. Rather than 
rehashing the book's contents, the focus 
of this article is on ways to bend and 
stretch The Mythical Man- Month to its 
extremes; to help reduce restrictions of 
progress due to communication break- 
downs and interdependencies. 

The author of The Mythical Man- 
Month, Frederick P. Brooks, Jr., puts forth 
an idea that probably isn't too shocking 
to most of us. He believes software engi- 



neering is radically different from all other 
forms of engineering primarily because 
there is no physical representation for our 
product. He argues that while studying 
the organization of other engineering 
fields can be useful, it cannot completely 
govern our particular craft. Fll extend this 
idea even further with another not-so- 
ground-breaking declaration: computer 
game engineering is by far the most eso- 
teric of all software engineering, because 
at its essence is the difficulty of developing 
the all-important fun-factor. 

About Schedules 

r~1 he two primary ways to control the 
1 inherent limitations imposed by The 
Mythical Man-Month are through sched- 
ule and process. While the scope of this 
article is on scheduling, a complementary 
feature covering the process side appears 
on Gamasutra.com. The Mythical Man- 
Month states that adding people to a 
project experiences a law of diminishing 
returns until a point where growing the 
team actually creates a net loss in 
progress. The essence of this idea lies in 
the complexity of software engineering, 
where each team member works on a 
virtual object with a significant amount 
of attachment to other pieces. All of 
these separate pieces must line up cor- 
rectly for the final product to succeed, so 
communication among people becomes 
an exponentially tightening bottleneck as 
the team expands. Translation: more of 
your day is being spent in meetings. This 



is especially true as the project gets closer 
to the end and the volume of history 
knowledge reaches its peak. However, 
while this general tenet is true, the rate 
of decline and the transition where the 
new person added causes a net loss in 
productivity is variable. The best way to 
control these variables is through knowl- 
edge of your project's scope and 
resources, especially the team's manpow- 
er. And this understanding must go 
beyond simple head counts and reach a 
true understanding that your team is 
made up of very different people who 
need to be managed in very different 
ways. An effective management strategy 
including schedule and process can pull 
significantly more productivity out of a 
given team and thus stretch The 
Mythical Man-Month to its limit. 

All successful projects must start with a 
schedule to understand the scope of the 
undertaking, no matter their timeframe. If 
you believe you don't have time to sched- 
ule, then I counter you don't have time not 
to. A schedule is your first line of defense 
against the communication breakdowns 
that kill a project's deadlines. 

Amazingly, I still encounter teams with 
extremely poor or even nonexistent 
schedules. In my early years in the busi- 
ness, I worked on three games called 
EsoTERiA, Tube Racer, and Beneath. 
Never heard of them? Exactly. The first 
was barely released and probably only 
sold a couple hundred units and the next 
two were both canceled after numerous 
schedule overruns. All suffered endlessly 



Michael Saladino I Michael just finished a year-long tour of duty at Microsoft Game Studios Publishing where he helped ship Counter- 
Strike for Xbox, MiDTOWN Madness 3, and Tetris Worlds Live. He's now at EA in Los Angeles where he's a development director, put- 
ting his money where his mouth is. Contact him at msaladino@gdmag.com. 
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The figure on the left shows how just adding people to the project does not add value and can actually diminish progress due to overloaded commu- 
nications. The figure on the right shows how improved scheduling can pull the maximum value line out and increase progress. 



from a lack of proper scheduling. Since 
then, I have shipped every game I have 
led on time, mainly due to great schedules 
which gave me the information I needed 
to mutate my team when new problems 
arose. In my last year at Microsoft pub- 
lishing, I've seen many games ship and 
many games killed: a constant theme run- 
ning through them all is poor scheduling 
leads to canceled projects. 

Project Life Stages 

To understand scheduling a game you 
must first understand the phases of 
existence that all projects go through. 
While the absolute time of each phase 
fluctuates based on the overall project 
length, there are common ratios of time 
between them. The first stage is concept 
development. You are in a creative peri- 
od when blue sky brainstorming is the 
goal. At this point, you have no need 
for real schedules beyond simply setting 
a deadline for finishing these initial 
meetings. Upon completion of this 
phase, you should have a well-defined 
design document with discussion of not 
just the gameplay but also art and engi- 
neering-centric sections as well. This 
should take approximately 1/8 of the 
total timeline or about three months 
from a 24-month project. 

The next stage is your prototype 
where you prove out the major 
unknowns, the foremost being the fun 
factor. This section is scheduled much 
like the whole game, only with an abbre- 



viated timeframe, normally around 1/8 
of the total project but sometimes grow- 
ing depending on initial technology. 
Obviously, the more stable the tool set 
and engine you start with, the more like- 
ly the prototype would fall within the 
three month estimate. If the prototype is 
successful, you should leave this phase 
with a strong understanding of what will 
make the game fun and an example pro- 
gram that conveys this idea. Along with 
this will also be a system-level task list 
with estimated time allocations for 
designing these new systems. In other 
words, all the major systems might not 
be done but you should know what they 
are and have a rough guess as to the 
manpower needed to complete their first 
pass. This is the phase when independent 
developers should begin shopping 
around to publishers. While some devel- 
opment houses are lucky enough to get 
signed with only paper presentations, 
showing up with a working prototype 
goes significantly further when trying to 
secure a deal. 

Your next stage is preproduction, 
which is when the team tackles the 
remaining uncompleted systems through 
at least the first implementation. For 
example, your new experimental lighting 
system with dynamic shadows should be 
up and running along with the decision to 
continue work on it or cut it due to prob- 
lems. You should also have your first cou- 
ple of levels completed to alpha quality to 
extrapolate the effort needed to complete 
the remaining levels. The first level 



always takes the longest and usually ends 
up being the worst because your team is 
getting used to the process and the new 
game you're making. So you must com- 
plete two or three levels so the team 
begins approaching what the real world 
manpower per level will be. Once you've 
done this, you'll be able to map out the 
rest of the time frame and know if you 
need to reduce the level count immediate- 
ly. This stage should take about six 
months from a 24-month project or 1/4 
of the total project. 

Now you enter full production, which 
is normally when your team hits its max- 
imum size (without the extras needed for 
test, which normally comes on later). At 
this stage, the game should be fun and its 
entirety should be known. This is where 
your system level task list is constantly 
being refined into smaller and smaller 
resolutions. The process is becoming 
mechanical now as opposed to the 
freeform conceptual stages in the begin- 
ning. Your schedule is now the end-all 
be-all of the project's existence. You 
should expect this time to last about nine 
months or a full 3/8 of the project mak- 
ing it the longest stage. This section of 
development ends with code and content 
complete meaning everything is in the 
game the way it was originally planned. 
It doesn't mean the game has to be com- 
pletely locked down as final changes can 
still be made well into alpha as long as 
proposed changes significantly improve 
the overall quality of the game with lim- 
ited risk. 
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And now we're brought to the end, 
the final stage. It's here that you've 
reached alpha and beta, also known 
respectively at Microsoft as code/content 
complete and zero-bug release (ZBR). 
These stages are mostly defined by long 
crunch times. Programming is focused on 
bug fixing, the art department on final 
polish, and the test team ramps up to full 
capacity. The schedule is becoming less 
structured and instead the team is being 
driven by daily and hourly updates 
derived from the test team along with 
oversight from the departmental leads 
and producer. Your bug-tracking soft- 
ware essentially becomes your schedule 
as you make your final sprint, which 
normally lasts about three months out of 
24 or 1/8 the total. 

Once you understand these stages of 
development, you'll be better able to 
schedule them. One important point is 
that these fractions are meant to be guide- 
lines, not strict rules. All projects expand 
and shrink these stages as they need them. 
While one project needs more time for 
prototyping, another needs less for pro- 
duction. Or perhaps your project is a 
simultaneous three-console release that 
will probably increase your absolute time 
spent in the final bug push. However, 
these guidelines should help you identify 
earlier when a particular stage is grossly 
beyond expectations. For instance, if you 
worked on a prototype for nine months, 
you shouldn't expect to complete the 
game in the next year. Your team obvious- 
ly created lots of new technology and 
gameplay if it took nine months for a pro- 
totype, so ramp-up time alone when 
building the full game will prevent your 



team from finishing in 
the coming year. 
Working at Microsoft 
publishing has shown 
these time ratios to 
work successfully for 
many projects includ- 
ing Counter-Strike 
for Xbox, which was 
essentially a five- 
month project, and 
Whacked, which was a 
two-year one. These two 
projects had completely dif- 
ferent absolute times but simi 
lar ratios between segments. 

Building a Schedule 

Traditional scheduling in the form of 
a Microsoft Project document or a 
simpler Excel spreadsheet is most criti- 
cal during the prototype, pre-produc- 
tion, and production phases of develop- 
ment. Concept development is too 
freeform and the final bug push is too 
reactionary; neither will benefit much 
from a schedule. The prototype phase is 
really just an abbreviated form of pre- 
production and production, so to 
understand those is to understand pro- 
totyping. Therefore, let's focus on pre- 
production, production, and the differ- 
ences between them. 

Creating a schedule first requires build- 
ing a task list, which is in fact an expres- 
sion of your design document. Are you 
building a racing game? Do you need a 
four-point suspension system? Do you 
need a flight control model? Is water sur- 
face dynamics critical to the boat level? 




24-Month Project Timeline 



Conceptional Protoype 
3 months 3 months 



O- 





Preproduction 
6 months 



Full Production 
9 months 



12 

Months 



15 



18 



Alpha/Beta 
3 months 



-O 

24 



21 



A sample timeline describing the phases of development. As actual project lengths and subjects 
vary, you can scale the proportions to fit your game. 



Do you need a custom lightmapper? 
These game features need to be filtered 
into independent engineering, art, and 
level-construction tasks. The resolution of 
these tasks is dependent on where you are 
in the timeline of your project. We begin 
with system-level tasks during pre-pro- 
duction and constantly refine these as 
milestones are started, progressed, and 
completed. By the time you reach produc- 
tion with the major unknowns resolved, 
you should be able to make a valiant 
effort to refine the entire schedule down 
to days, but don't. Tasks should initially 
be timed at a resolution of about a week. 
Anything that needs to be completed in 
the next two months should be resolved 
down to days. Refining the resolution too 
much, too soon will be work wasted 
since the dynamic nature of a schedule 
will lead you to redo it anyway. 

Understand the Team 

he next stage is understanding your 
* team's manpower. You should begin 
by identifying the type of developer (any 
team member including programmers, 
artists, level designers, and so forth) each 
person on your team is. One simple way 
to do this is to analyze how they fall into 
four basic types, based on combinations 
of skill and dedication. These types can be 
represented on a simple 2X2 matrix with 
their skill level on one axis and their dedi- 
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cation on the other. Developers near the 
low end of both axes, those with little 
skill and poor morale, should be removed 
from the project after attempts are made 
to improve their dedication. Skill takes 
significant time to improve so don't expect 
that to rise over the course of one project, 
but a person's morale certainly can. 
However, if you can't promote improve- 
ment in a reasonable time, say 1/4 of the 
total project length, remove them from 
either the project or the company. Too 
many leads allow poor performers to stay 
in positions where they drop the ball and 
bring down the morale of those around 
them. Removing a poor performer can 
quite often create a net gain for the entire 
team even with the loss of the head. My 
previous work at Presto Studios showed 
me first-hand the damage one or two low- 
end members can do to the overall work- 
load and morale of a team. 

The next type of developers are the 
highly skilled persons who are poorly 
motivated. Maybe they don't like the 
game. Maybe they're angry because they 
didn't get the lead positions. Maybe they 
just came off a horrible crunch and just 
aren't ready to dedicate long hours again. 
Whatever the reason, they simply want to 
work their 40 hours, do their job effec- 
tively, and then go home. But since they 
are still highly skilled they are valuable in 
their own way. They will be most useful 
when working on exactly what they want 
to work on. If they're masters of net- 
working, then that's where they go. They 
will put up with the least amount of 
unpleasant work when compared to the 
other developer types. Due to their skill 
level, they will require less hand holding 
but their strict hours mean keeping them 
on their schedule will be most critical. 
Luckily, their own sense of pride will 
often be their strongest motivation for 
getting the job done right and on time. 

Then we have the young kids straight 
out of college with little skill but miles of 
desire. These developers want to prove 
themselves but they can get over their 
heads very quickly. Give them the systems 
with the most design in place. Put them in 
positions where they have the most num- 
ber of seasoned developers working with 
them. They should be given non-perform- 
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A developer productivity matrix. 

ance-critical code such as UI. They should 
be watched over by more experienced 
mentors and be expected to make up for 
their inevitable schedule overruns with 
long hours. At this point in their career, 
they are paying their dues. And if their 
rookie mistakes are kept to a minimum by 
monitoring them closely, their ambitious 
attitude can help light a fire underneath 
everyone in the group. 

And finally, we are brought to the most 
important people on the team: the super- 
stars. They are the highly skilled, highly 
motivated crew that makes the impossible 
possible. This is the white-hot fiery core of 
the sun that will drive your project when 
things get tough. They will work week- 
ends without even being asked. They will 
bring in sleeping bags when necessary and 
work all night if needed to get back on 
schedule. Work for a 1:3 ratio between 
superstars and the other two types of 
developers. (Remember, you should have 
already fired the first group so we're only 
left with three total groups.) Your super- 
stars are your first and last line of defense 
against missing your milestones. 

Assign the Team 

||P^nce you understand your team, you 
can successfully begin to assign peo- 
ple from your pool of talent to the task 
list you have built. Assign the highly 
skilled but poorly motivated people first. 
Give them the systems their skills match 
and they are interested in building. If you 
run into conflicts such as too many 
physics programmers all wanting to own 



the system, try to exchange these 
resources with other teams. You do not 
want highly-skilled, poorly-motivated 
people working on systems they don't 
want to. If you do this they will most 
likely start dragging their feet or sending 
out resumes. Next, layer in the superstars 
who most Hkely can do almost any sys- 
tem you assign to them. These people 
have written graphics, physics, sound, 
AI, and most everything else so skill 
matching should be less important. After 
they have been placed, the first two 
groups of developers should cover every 
major system, leaving the eager rookies to 
round out the corners and fill in the gaps. 

With people assigned to the task list, 
the lead should take the first pass at 
assigning time to each job. Be Hberal 
with your estimates; optimism is a swift 
killer of any schedule, so assume mis- 
takes will be made. Go ahead and 
assume your difficult, product-defining 
systems will need to be rewritten two or 
three times. Once completed, bring your 
team together and as a group discuss 
your estimates, gather contrary opinions, 
and negotiate final estimates for the 
schedule. Remember, even though you're 
the lead, it's the persons you've assigned 
to the task who have to complete it in 
the scheduled time. Give them the final 
word if you can't come to a consensus. 

You now have a full task list complete 
with people and time, however it's still 
not a schedule. I've seen many projects 
over the years stop at this point without 
truly turning the task list into a schedule 
by serializing the pieces. This process 
begins by determining dependencies 
among the tasks. You can't texture a 
level until it's been modeled. You can't 
animate a character until it's been 
skinned. You can't program the front-end 
UI screens until a base GUI system is fin- 
ished. This is what creates a timeline that 
shows people what they should work on 
on any given day. This is also how you 
can identify the communication depend- 
encies that lead to one of the central 
tenets of The Mythical Man-Month. It's 
at this point that you can see just how 
interconnected your different systems and 
the programmers building them will have 
to be to complete the project. 
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We now must lay this data into our 
schedule software. Put each person down 
for six hours a day for five days a week. 
Even if you expect a death march, don't 
start by scheduling for it. That's a sure bet 
at blowing your deadlines down the road. 
The six-hour day covers the time during 
an eight-hour day the person will be in 
meetings, taking lunch, or hanging out in 
the kitchen eating a muffin with the team. 
Remember to put in holidays. (I laugh 
every time I see a schedule with someone 
completing a task on Christmas Day.) And 
as a general rule of thumb, assume each 
developer will take one personal week of 
time every four months. 

Now you might look down at your 
schedule and think something has gone 
horribly wrong. One or two people in 
the schedule will have way too much 
work that puts them months or even 
years beyond the rest of the team. 
Workload balancing is required to fix 
this problem. Move tasks to other devel- 
opers, starting with the easiest, but 
remember as tasks move away from their 
ideal owners they may need additional 
time padding for someone not as familiar 
with the system. This is also when the 
idea of additional developers should be 
first introduced. If you have a hard date 



for delivery and the tasks just don't add 
up, start padding your team with TBD 
(to be decided) members. This true and 
honest schedule will be your ammunition 
to request more support from your boss. 
Fight the urge to simply schedule for a 
crunch this early in the process. If you 
can't get the people you need on this 
schedule, then make it clear cuts must 
begin now. By following these steps, you 
can start making these hard decisions 
early instead of in the final months. 

After days or weeks of working out 
the tasks and timeframes, you now have 
a schedule. You should know the size of 
your team, the tasks they perform, the 
order in which they will perform them, 
and how long the total project should 
take. Of course, it's all a big educated 
guess at this point but it's infinitely better 
than nothing. And remember that the 
schedule is a living document that should 
be updated daily by the owner. Don't be 
afraid to change it and make sure people 
know when their sections do change or 
when a major overhaul is needed to 
bring the schedule back into reality. If 
any one person falls behind his or her 
milestone deliverable time by more than 
10 percent, the problem should be 
addressed that day. Maybe the person 



just needs to talk the problem out with a 
mentor. Maybe he or she needs assistance 
with the volume of work. Maybe some- 
one else can take one item off the plate 
to give the person a couple of extra days. 
Be honest with the schedule. The more 
truthful the schedule is, the more flexible 
your team will be. 

A schedule is knowledge. Yes, it's a 
human construct and therefore ultimately 
flawed, but it's still the best way project 
managers have to understand what lies 
before them. It's your map through the 
jungle and you'll be glad you have it even 
if a couple of the trails are mislabeled. 
With this information you'll be able to 
stretch your team into shapes and forms 
everyone around you will claim are 
impossible. And even if you do miss a 
milestone, a well-built schedule will help 
everyone believe you're only missing one 
instead of the constant slide most doomed 
projects face. 

My next article (available at 
www.gamasutra.com) discusses process 
and useful ways to implement your new 
schedule, so your team can continue 
breaking new ground in game develop- 
ment while you keep the communication 
nightmare off their backs. Now get back 
to work, you have a schedule to write! # 
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A segment of the Microsoft Project schedule used for developing Counter-Strike for Xbox. 
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Game Developers 
Conference 

2004 

PREVIEW 



The Set-Up 

Throw together more than 10,000 attendees, 400 speakers, 
200 exhibitors, hundreds of journaHsts, and a doomed 
San Jose downtown resigned to being overrun for a week, 
and a Game Developers Conference is born. The GDC (which is 
produced by the CMP Media Game Group, which also publish- 
es Game Developer) is now in its 18th incarnation, facing the 
continuing challenge of offering up structure to the uninitiated 
along with fresh, unexpected experiences for the wizened indus- 
try veteran. 

Recent forays into specialized mini-conferences, such as GDC 
Mobile (returning this year March 25 and 26) and the IGDA 
Academic Summit, have attracted new faces to the event, but 
not to be lost in the whirlwind of activity is people's fundamen- 
tal desire to connect meaningfully with like-minded colleagues. 
Bonds forged in months and often years of newsgroup and e- 
mail correspondence might culminate in face time meticulously 
planned or happily spontaneous, while new connections help 
attendees move forward. 

Whether you're one of the old-school GDC alumni or an 
incoming freshman, let our guide point the way to some of the 
interesting people and events at the 2004 Game Developers 
Conference. 
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Many interesting speakers are mak- 
ing their first GDC presentations 
this year, including: 



John Carmack. Though his pro- 
gramming-track keynote topic remained 
at press time as elusive as id's next Doom 
installment, thousands will no doubt turn 
out to see what this game development 
icon has to say. As befits this coding wiz- 
ard-cum-aerospace dabbler, prepare for 
some actual rocket science. 



Eiji Aonuma. The designer/director 
of numerous Legend of Zelda titles, 
including the most recent Wind Waker, 
arrives on GDC's shores to discuss "The 
Evolution of a Franchise: The Legend 
OF Zelda." Anyone trying to move a 
mature franchise forward in today's 
competitive marketplace can learn some- 
thing from the venerable Zelda series. 



Masahiro SakuraL Late of HAL 

Laboratories, Sakurai (Kirby's 
Dreamland, Super Smash Bros.) is 
now taking his show on the road, by 
developing for multiple platforms and 
talking openly about his design work in 
"Game Design: Risk and Reward." Risk: 
Do players really want to beat the snot 
out of cute little Pikachu? Reward: Yes, 
they most certainly do. 



YanniS Mallat. Can scrappy young 
teams of can-doers really still give their 
all and turn out amazing games? Ubi 
Soft's Montreal-based Prince of Persia: 
The Sands of Time team says oui. 
Executive producer Mallat reveals how 
the magic came together in his lecture, 
"Reawakening a Classic: Prince of 
Persia Case Study." 



Kenji Kaido and Fumito Ueda. 

ICO's producer (Kaido) and director/ 
designer (Ueda) reveal how they set out 
to make a very different game and bring 
never-before-seen attention to detail to 
the medium. With their backgrounds in 
game production and fine arts, they show, 
in "Game Design Method of ICO," how 
methodology and artistry can work 
together to create unforgettable games. 



1L 



The 4th Annual Game Developers Choice Awards 

Every year sees more game awards doled out, from a wider variety of 
sources. Still, the GDC Awards, presented by the IGDA, remain the only 
major venue where developers are honored by their peers and get to address 
them as such. The posthumous presentation of last year's Lifetime 
Achievement Award to the family of Nintendo's Gunpei Yokoi left nary a 
dry eye in the house. Don't miss the presentation of the 6th Annual 
Independent Games Festival as well. March 24, 6:30-9:30 p.m. 



Experimental Gameplay Workshop 

The EGW started out two years ago as an unknown side session, but the 
room quickly overflowed, proving that despite rampant sequelitis there are 
plenty of people in the industry who care about innovating within the inter- 
active medium. Organized by Game Developer's own "Inner Product" 
columnist, Jonathan Blow, the EGW has quickly become a must-see for wet- 
eared newbies and hoary veterans alike. March 25, 3-6 p.m. 



Gamehotel: Games and Digital Pop Culture 

Gamehotel is a brand-new event to GDC, as its organizers, Paris-based TNC 
Network, further their self-stated goal of "pointing the direction to the 
future of innovative and diverse interactive entertainment" by going straight 
to the creatives at GDC. Combining presentations and demos from such 
industry darlings as Tetsuya Mizuguchi (Rez) and Masaya Matsuura 
(Mojibribon), emerg- 
ing-platform game 
designers, and a 
menagerie of wacky 
Asian action-figure 
makers, the event 
promises an eye-open- 
ing experience. 
March 25, 6-8 p.m. 




I John Gaeta Visual Arts Keynote 

Anytime a visionary, artistic speaker promises a "stream of consciousness- 
style discussion" on any number of multiple topics, you know you're in for 
either one of the best or worst talks of your life. Let's hope the plot of his 
presentation, which may or may not include "creative empowerment for the 
average Joe," "schooling your grandparents on a Playstation 3," "how to 
properly set fire to hard drives," "the death of The Matrix^''' and "some other 
visual effects stuff" holds together better than the trilogy's. March 26, 12-1 p.m. 



«t Developer Business Summit: An IGDA Think-Tank 

The days of ham-handed business management are numbered in today's 
high-stakes game development industry, yet proven, replicable strategies 
remain elusive. This in-depth two-day summit brings business leaders from 
development studios big and small together with publishing insiders to help 
plot a course for business success in game development. 
March 22 and 23, 10 a.m.-6 p.m. 



www. gdmag .com 
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The entire Game Developer edi- 
torial staff will be at the show, 
and we're all putting together our 
own agendas. Although session 
times and dates were not final at 
press time, here are some of the 
goings on that Managing Editor 
Jamil Moledina, Departments 
Editor Kenneth Wong, and Product 
Review Editor Peter Sheerin are 
planning for. 




IL S GDC PICKS 



How to Write an Unforgettable Story 

]ohn McLean-Foreman 
Evocative storytelling is essential to 
memorable entertainment. As a 
moonlighting novel writer and film 
critic myself, both professional and 
personal interests compel me to 
attend this one-day tutorial. 
A Peek Behind the Shqji: The 
Japanese Videogame Market Today 
Ryochi Hasegawa 
For years, Japan was the Mecca of 
game innovation. While rumors of 
its game market's demise may be 
premature, I wonder what it takes 
to chart a game through the shift- 
ing generalizations. 
Interfacing with Hollywood: 
Challenges and Opportunities 
Keith Boesky, Leonard Grossi, 
Jason Rubin, Larry Shapiro 
Unfortunately, the movie industry 
has no USB port. But they do have 
representatives on this panel. I'm 
hoping they'll offer some insight 
into creating mutually beneficial 
licenses. 

The Secret of Pac-Man's Success: 
Making Fun First 

Toru Iwatani 

Why couldn't millions around the 
world, including myself, stop play- 
ing this game? This session doubles 
as therapy. 

The History of Animation 

Phil Tippett 

Salvador Dali traveling through 
time to talk about surreal game art 
would be slightly less interesting. 
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What to Do When All Goes to Hell 

James Gwentzman 

Considering the erratic nature of 

game development, it's never too 

cautious to be prepared for the 

worst-case scenario. 

IGDA Women's Group Gathering 

Jessica Lewis 

This is a great opportunity for me to 
learn more about the gripes and con- 
cerns of an underserved sector of 
developers. Plus, I'm single. 
Developing a Massively Multiplayer 
Game 

Raph Koster, Rich Vogel, 
Gordon Walton 

It'll help me understand what it 
takes to efficiently manage the mas- 
sively multi-developer team (100+) 
required to create such a game. 
Immigration for Foreign Games 
Professionals in the Age of Homeland 
Security 
Ron Rose 

Rose's tips on compliance issues 
concerning hiring and contracting 
foreign talent should give me a better 
picture of what international game 
development teams face today. 
Acting for Animators 
Ed Hooks 

I'm interested to see how Hooks 
distinguishes animation invested 
with emotion from animation 
devoid of motive. 



DC PICK 



Real World Multi-Threading in PC Games 

Aaron Coday, William Damon, 
Maxim Perminov 

While the potential for enhanced per- 
formance is quite real, so is the poten- 
tial for diminished performance if 
done poorly or mismatched with all 
the CPU features. 
Developing Wireless Location-Based 
Games 
Jay Aguilar 

This could create a new genre of 
videogames, and I'm curious to see if 
its use here is better than the horrid 
experience I've had with location- 
based WAP content. 
Advanced OpenGL Tutorial 
Cass Everitt, Simon Green, Evan Hart, 
Bill Licea-Kane, Rob Mace, John Spitzer 
Not all games revolve around DirectSD, 
and the coming of the OpenGL shading 
language is definitely something to keep 
an eye on. 

Advanced Visual Effects with DirectSD 

David Gosselin, Jeff Grills, Shawn 
Hargreaves, Richard Huddy, Gary 
McTaggart, Jason Mitchell 
This all-day tutorial from the leading 
experts on the DirectSD technologies 
in DX9 should teach you about the 
latest techniques for eye-popping 
imagery. 

Government Simulation in 3DS Max 

Brian Blau, Stephen Langmead, Mike 
Rasmussen, Douglas Whatley 
The use of videogame technology in 
government applications is an oppor- 
tunity for growth, and seeing how the 
rapid rate of technological change in 
games mixes with the government's 
pace may be illuminating. 
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NOTABLE ROUNDUP 



Roundtable sessions are where the 
massive scale of GDC gets back to 
more intimate, grassroots discussions. 
Many attendees carry away their best 
GDC memories from the spontaneous 
but profound conversations around 
roundtables. The outcome depends on 
who shows up, making some sessions 
inimitable sources of inspiration, and 
some of them poorly attended duds. 
Here are a few sessions that ought to 
provoke lively debate. 
Quality of Life: The Next Step. 
If moderator Francois Dominic 
Laramee successfully moves the discus- 
sion beyond cathartic renditions of 
crunch-mode horror stories, developers 
can share ideas on how the IGDA 
should steer its efforts to promote bet- 
ter balance between a game develop- 
ment career and life outside the office. 
User Created Content: Is It Worth It? 
As project director of BioWare's 
Neverwinter Nights, moderator 
Trent Oster should have a good per- 
spective on this contentious issue. 



Players want to get more, developers 
have less to give. But is putting tools 
and creative power in your customers' 
hands good for developers and their 
prized brands? 

By the Books: Solid Software 
Engineering for Games. Now in their 
third year, these popular sessions (one 
on each conference day) attempt to 
tackle game programming's $64,000 
questions. Moderator Noel Llopis 
enables participants to compare strate- 
gies for language use, documentation, 
testing, tools, and more. Newer 
methodologies such as extreme pro- 
gramming are also discussed in a 
game development-specific context. 
The Publisher's "Rules of Acquisition." 
Tantalized by the idea of a juicy sellout? 
Just want to be prepared on the off 
chance that a publisher shows up at 
your doorstep with sacks of gold-pressed 
latinum for you and your hardworking 
partners? Attorney Tom Buscaglia hosts 
a free-for-all where non-Ferengi types 
can discuss how to successfully jump 
through the business hoops of acquisi- 
tion without tripping up. 




GDC at Work: Deploying an Open 
Interactive Audio File Format 

Imagine where 3D graphics development would be without 
the advent of OpenGL and you can understand the impetus 
to create a nonproprietary, royalty-free interactive audio stan- 
dard. Members of the Interactive Audio Special Interest Group 
(lA-SIG), in tandem with the MIDI Manufacturers Association, 
are pursuing just such a goal in the ongoing development of 
Interactive XMF, the extensible Music Format for interactive 
audio, which they presented at last 
fall's Audio Engineering Society (AES) 
Convention. 

Chris Grigg, George Sanger, and 
Martin Wilde will host an hour-long 
session, "Cross Platform Audio Using 
Interactive XMF," to present the cur- 
rent status and goals of the effort, 
offer opportunity for community 
input, and drum up support from 
developers who they hope are as tired 
of reinventing the wheel as they are. 
Now that audio is becoming more of a 
selling point for games, reducing ineffi- 
ciencies and rework in audio develop- 



ment can benefit many developers, from the creative visionaries 
to the bean-counters. For more information, see Linda Law's 
Gamasutra article on the subject, at 

www.gamasutra.com/resource_guide/20030528/law_01.shtml. 



PSP Peek 



W 




ell before Sony is expected to unveil PSP plans at E3 
formally in May, SCEA's David Coombes and Peter 
Young will attempt to demystify Sony's 
new machine for its new and hopeful 
developers in their presentation, 
"Programming for PSP." No doubt 
they'll go over high (and perhaps some 
low) points of the specs in detail, offer 
development resource scenarios, and 
outline Sony's developer support plans 
for the device. They're also planning to 
address how the machine's graphical 
capabilities might affect handheld 
game design, making this session a 
prime stopping point for game design- 
ers and producers as well. Won't you 
throw in some free samples, guys? # 
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ETT yOUNG, MARIO RODRIGUEZ, AND CHRIS PICKFORD 

Garret fs eight-plus Microsoft years span from testing NBA Full Court Press to exec, 
producing the PGR series with Bizarre. Mario began testing games at Microsoft as a 
2002 University of Miami grad, recently working on PGR2 and RalliSport 
Challenge. Chris has been designing and testing at Bizarre for four years, shipping 
the PGR series and FuR Fighters. 
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ojECT Gotham 




GAME DATA 

BLISHER: Microsoft Game Studios 
FULL-iiMt CUKt itM«v,. 40 




MAX TEAM SIZE (including test, 
licensing, localization, and other 
support resources): 102 
LENGTH OF DEVELOPMENT 2 years 
RELEASE DATE: Nov 18, 2003 
PLATFOI Xbox 
ir^^wB-i onijiirMT ii ApnvA/Aor Pentium 

600MHz-2.4GHz machines with 
256-1 02Z^MB RAM, GeForce 2-4 series 
and ATI Radeon 9700 Pro video boards. 
UbVhLUPMtNi bURWARIz: Microsoft 
Visual Studio .NET Microsoft SourceSafe, 
Alienbrain, built-in 3D Editor Softimage 
XSI, Araxis Merge 2001 , SoundForge 
37,174 files, 219,538 
lines of code, 41GB of data 
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ROjECT Gotham Racing 2 

is the sequel to the be 

^^^^■^H seUing Xbox racing game, 
developed by Bizarre 
Creations (Liverpool, 
England) with production and publishing 
support from Microsoft Game Studios. 
Our two teams rolled directly into produc-" 
tion after finishing international versions 
of PGR in February 2002. We significantly 
expanded the scope and quality of the 
combined team, bringing on new artists, 
programmers, and testers. Our ultimate 
goal for this project was to create a AAA 
PGR title for the 2003 holiday season 
built upon the fundamental strengths of 
the PGR franchise and innovate in our 
use of the Xbox's online system, Xbox 
Live. Given our on-time delivery and the 
game's 92.4 percent average score from 
over 70 reviews (referenced from 
www.gamerankings.com), we feel that we 



achieved our goals. 

We owe that success to the strength of 
our people and the clarity of our chal- 
lenge. Smart, effective, hard-working peo- 
ple are critical to achieving any worth- 
while goal, and our two teams had that in 
spades. Though there were some disagree- 
ments and late changes in tactical direc- 
tion, everyone on the team was always 
working toward a clear overall strategic 
vision for the project. A key ingredient to 
our ultimate success was the strong rela- 
tionship between developer and publisher: 
matching Bizarre's design, technical, and 
artistic strengths with Microsoft's 
strengths in testing, licensing, usability, 
creative writing, and production manage- 
ment. Without an extremely high level of 
trust, we would not have been able to 
maximize the efforts of each team, and 
PGR 2 would not have been as strong. 

Our hope is that this postmortem can 
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provide some insight into how we 
worked together to build Project 
Gotham Racing 2 — the things that 
worked well, and the things we would do 
differently if we had to do it all over 
again. With luck, we hope other teams 
will be able to apply these lessons to 
improve their processes and avoid some 
of our pitfalls. 



What Went Right 

1 Strong early vision for innova- 
# tion. In our efforts to build on 
the market success of PGR, we knew it 
was critical to stay true to and build on a 
formula gamers loved. We decided to 
greatly expand the number and diversity 



of cars (from 25 to 100) and cities (from 
four to 11). Our artists invested signifi- 
cant time in researching routes through 
cities we felt were interesting, recogniza- 
ble, and fun to drive. As we broadened 
the scope of the car list, we added new car 
categories like classics, muscle cars, super- 
cars, and even SUVs. The designers also 
expanded the Kudos system to increase 
the reward for skillful driving, adding 
rewards for taking a "good line" through 
a corner, drafting, and navigating track 
sections cleanly (without hitting walls). 

But as a new PGR game, we knew we 
had to continue to push that spirit of 
innovation. Though Xbox Live was an 
unproven and unknown technology dur- 
ing our initial design planning, we com- 
mitted to pushing the online frontier in 



PGR 2. We bet gamers would love racing 
online against their friends, and we 
decided to incorporate Xbox Live 
Scoreboards for each race in our game. 
These interactive high-score rankings 
allow every gamer with an Xbox Live 
account to post a race result, and allow 
the top 10 racers to post their actual race 
ghost replay for anyone to download and 
watch (or race against). 

There were major challenges inherent 
in each decision. To build all the new 
cars and cities, we virtually doubled the 
size of the original art team, which also 
increased the challenges in team manage- 
ment and communication. Relying on 
unfinished technology from external 
teams created a large bottleneck in our 
production schedule, as we awaited their 
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ABOVE. A Porsche Camera GT edges out a Saleen S7 on the Sydney waterfront. 

LEFT. A classic Porsche Carrera purrs loudly on a bridge in Yokohama. 

PREVIOUS PAGES. A Ferrari Challenge Stradale scares off tourists at the Duomo in Florence. 



deliverables. We chose to accept these 
challenges head-on, given our vision to 
expand the scope of the game beyond the 
original title. 

2 Reducing worldwide manage- 
# ment. The Bizarre Creations 
team included all of our core developers, 
artists, game and sound designers, and 
production staff. The Microsoft team in 
Redmond, Washington included many 
production and design support staff, 
licensing managers, a full test team, and 
the marketing team. Given the impor- 
tance of our international release, we 
had localization staff working full-time 
in Japan, Korea, Taiwan, and Ireland. 
We also employed 3D art vendors in 
Australia and England, and translation 



vendors in France. 

During production, members of the 
team visited locations all around the 
world to gather research, reference 
material, and recordings. We shot thou- 
sands of photos and hundreds of hours 
of video in each city. We recorded real 
DJs in Moscow and Tokyo. We even 
made a special trip to the Promised 
Land, visiting the Ferrari plant in 
Maranello, Italy to photograph and 
record engine audio of the Ferrari Enzo 
before it was released to the public. To 
borrow an old British saying, the sun 
never set on the PGR 2 team. 

Managing such a global team created 
many problems in communication and 
schedule management. Our approach to 
solving these problems was to actually 
reduce, rather than expand the amount 
of management. We built up strong com- 
munication channels between all mem- 
bers of the team, removing the communi- 
cation bottleneck that can occur at the 
producer level on game projects. All 
members of the production support staff 
at Microsoft were empowered to interact 
directly with all of their peers and other 
members of the Bizarre team. The 
Redmond testers and Liverpool develop- 
ers interacted directly through the bug 



database, e-mail, and phone calls. The 
Liverpool art team worked closely with 
the Redmond licensing managers on 
approvals and change requests from 
vehicle manufacturers and other external 
licensors. All members of our interna- 
tional localization teams interacted 
directly with our UI developer. 

As most teams do, we also planned 
goals and deliverables for each milestone 
over the life of the production schedule. 
However, it was the people we had in 
place and our open communication 
channel team-wide that were the greatest 
contributors to our ability to resolve 
issues quickly and hit our aggressive hol- 
iday release schedule. 

5 Proving stable online game- 
# play early. Online multiplayer is 
frequently the highest risk area for any 
game, since multiplayer features can be 
the hardest to implement and require sig- 
nificant optimization and tuning. We 
addressed this problem early by imple- 
menting the bulk of our network code, 
physics optimizations for interpolation of 
car speed and trajectory across all boxes, 
and support for all Xbox Live features 
by early April, 2003, five months before 
release. Our overall multiplayer execu- 
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LEFT. A photograph of a bridge in Sydney. 



tion was relatively smooth, with only 
performance and voice issues to resolve 
during our final code optimization phase. 

We were able to achieve positive 
results by hiring a strong network pro- 
grammer, working closely with the Xbox 
Live team to fully understand the new 
technologies as they were being built, 
and synchronizing our implementation 
and test processes. Implementing a major 
set of Xbox Live features to the require- 
ments of the Xbox certification team 
required educating our team immediately. 
This investment paid off later by allow- 
ing us to quickly implement new APIs as 
Xbox Live 2.0 features such as stats with 
attachments (to support upload of ghost 
replays) were completed late in our proj- 
ect schedule. 

Testing's early involvement quickly 
identified lag and interpolation problems, 
and allowed us to troubleshoot new 
Xbox Live features such as friends, voice, 
and Scoreboards during initial implemen- 
tation, which allowed the development 
team to stabiUze new features earlier. 

As a result of proving multiplayer sta- 
bility early on, we were able to eliminate 
a major risk to our production schedule 
and focus our efforts on other gameplay, 
tuning, and polishing issues during the 
endgame. 

4 Driving user feedback into 
• product design. Designing a 
game under tremendous time pressure 
can often create a myopic approach to 
interface design and play balance. The 
team is so close to the game during 
development that objective evaluation of 
the inherent challenge and usability 
becomes difficult if not impossible. 
Schedule requirements limit valuable itera- 
tion time, and members of the team can- 
not represent the diversity of skill across 




MIDDLE. A wireframe version of that bridge. 



the spectrum of all end users. The theory 
"a user is only a 'new user' once" pre- 
sumes everyone in your audience will be 
willing to struggle through a confusing 
interface and unbalanced difficulty levels 
to experience and enjoy your game vision. 

We had success in addressing these 
challenges on PGR 2, but not without 
serious investment of people and itera- 
tion time over the last few months before 
release. We spent literally hundreds of 
hours hand-tuning each car, to balance 
realistic handling with ease of use. We 
used the Microsoft usability and con- 
sumer playtest labs extensively to seek 
out feedback from racing gamers, and see 
first-hand their initial experience and dif- 
ficulty navigating our interface, under- 
standing the Kudos system, and achiev- 
ing the micro-goals of each race mode. 

Aside from finding and fixing all func- 
tionality and content bugs, our greatest 
efforts during the endgame were put 
towards balancing our gameplay difficul- 
ty. Almost everyone across the teams in 
both Liverpool and Redmond — and many 
others not already on the PGR 2 team — 
spent time providing play-balance feed- 
back on specific challenges, each of the 
five difficulty levels, and the overall rate 
for unlocking cars. Considering the scope 
of the game, the size of the audience, and 
the concerns we had about exposing 
"golden paths" (shortcut cheats to high 
scores) in the scores and ghosts posted to 
our Live Scoreboards, we were very happy 
with the results achieved during our 
intense and collaborative tuning period. 

5 Effective licensing manage- 
# ment. Real- world authenticity is 
a core characteristic of the PGR franchise: 
real cars, real cities, real radio stations 
with real DJs, and real music from real 
bands. Unlike movie makers, game mak- 




RIGHT An in-game screenshot of the bridge. 



ers are required to get contractual 
approval with the owners of each logo 
and likeness before releasing it in a game. 

With 11 cities (including a real-world 
race track), over 100 cars, unique DJs for 
each of our 33 radio stations, and over 
300 songs, this was a monstrous task. 
We employed a team of five licensing 
managers over the course of the entire 
project to own and execute on this task, 
estabhshing contacts and maintaining 
relationships with all appropriate parties, 
facilitating review of all in-game assets, 
and working closely with legal counsel to 
close down each contract. 

The Hcensing team's contributions 
were vital. Not only did they enable our 
artists to fully realize the authenticity of 
each city, they also secured the appropri- 
ate rights, without which we would not 
have been able to include Ferraris, 
Porsches, BMWs, or any of the other real 
cars in PGR 2. 

What Went Wrong 




Synchronizing production 
• deliverables worldwide. As 



mentioned previously, managing the con- 
tributions of our worldwide team was a 
great challenge, and we feel that process 
went well overall. However, as with any 
huge challenge, there were major prob- 
lems that surfaced in some core areas of 
production. 

Our original plan for addressing the 
problem of recording, processing, and 
implementing source material from our 
worldwide car list was to distribute the 
workload and take advantage of our 
global resources. This ended up causing 
more problems than it solved. Crucial 
implementation and tuning time for each 
car was sacrificed, as all cars were not 
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A Porsche 91 1 GT1 burns rubber on the streets of Chicago. 



recorded to identical specifications and 
many cars were recorded very late. 
Additionally, an essential member of the 
sound design team moved to California 
and attempted to continue to fill the role 
part-time, adding friction to an already 
weak process. A related problem also 
occurred with the DJ scripts we recorded 
in each local city, as long contract and 
recording schedules delayed implementa- 
tion beyond our desired dates. 

This failure taught us two lessons. 
First, we needed to better synchronize 
content creation and implementation in 
the future. Second, we were reminded of 
a challenge all Microsoft-published proj- 
ects face: synchronization of the imple- 
mentation and test teams. 

Though all the developers, artists, and 
designers at Bizarre were working in real 
time within the same bug database as our 
Redmond testers, licensing managers, and 
international localization teams, we did 
experience many setbacks. At 4GB, our 
transfer time for builds was substantial, 
and we were forced to change file transfer 
tools three months before release. Some 
obvious bugs in Redmond were difficult 
to reproduce in Liverpool, as the testers 
verified builds that were at least a full day 



behind development. The 5,000-mile dis- 
tance between teams greatly increased the 
risk associated with any last-minute file 
changes at the end of the project. 

Though we made some great strides to 
better synchronize implementation and 
testing, our challenge moving forward 
will be to hit our functionality and con- 
tent deadlines more effectively, increase 
the stability of the build process, and to 
increase the scope of smoke tests in 
Liverpool before builds are sent over to 
the Redmond test team. 

2 Design took too long. 
# Incomplete design had the single 
largest impact on the slide of deliverables 
throughout our project schedule. Though 
we all understood and agreed upon the 
fundamental vision for the franchise, we 
started our PGR 2 design document very 
late, and we were still updating this docu- 
ment after feature freeze and E3 as new 
ideas cemented. We ended up overhauling 
many elements of our design several times, 
such as the user interface. Kudos reward 
values, and overall game structure. 

There were many critical factors that 
extended our design phase. Our designers 
were spread too thin early on, and we 



pursued many different paths and game 
modes before hitting on a concrete plan. 
Martyn Chudley, the creator of the PGR 
franchise and head of Bizarre Creations, 
played a critical part in stepping in to nar- 
row the focus of the overall game design 
in early 2003. 

Iteration on the handling characteris- 
tics of each vehicle proved incredibly 
challenging, and was completed very late 
in the schedule. As with any simulation- 
quality racing game, each change in vehi- 
cle handling has a significant knock-on 
effect on each car's usability, the perform- 
ance of the AI, the class and competitive 
categorization of each car, and the diffi- 
culty-level setting for each race. 

Quadrupling the number of cars from 
PGR to PGR 2 more than quadrupled our 
vehicle-tuning time, as the broader scope 
of vehicle content required far more dili- 
gence, testing, and tuning between indi- 
vidual vehicles and classes. We underesti- 
mated the initial scope of this effort. 

To combat these problems we expanded 
the size of the test team, pulled in addition- 
al designers from other projects, and hired 
a small team to execute specifically on the 
play-balancing task. Moving forward onto 
future projects we will seek out additional 
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LEFT. The Bizarre Creations PGR 2 development team. RIGHT. The Microsoft Game Studios PGR 2 production and publishing team. 



solutions, such as fleshing out key sections of the design document 
earlier, prototyping new gameplay elements in offline builds, and 
proactively scheduling our extensive play-balance efforts. Iteration 
is a natural part of game development and we're pleased with the 
results, but getting there was no easy task. 

S Relying on new technologies from external 
# teams. PGR 2's design called for online features to be 
integrated within almost every area of the game. These features 
required APIs that were still in development by the Xbox Live 
team as our schedule progressed, raising many significant 
obstacles and time constraints. 

While our Scoreboards were an extension of the system 
shown in the 2002 Xbox Live starter kit's MoToGP demo, we 
utilized them to a far greater extent than on other titles. 
Coupled with new Xbox Live features, such as stats with attach- 
ments (such as ghosts), and the high volume of Live users we 
anticipated, we knew that we had placed a big bet on bringing 
these emerging technologies to a usable and stable state. If any 
piece failed, the system would have failed. Implementing the 
new attachments APIs for uploadable and downloadable ghosts 
presented us with unpredictable problems, as we were pioneers 
in this space. The Xbox ATG team was extremely supportive, 
but they were also pushing hard to complete features for their 
own deadline. 

One example of a problem we should have been able to 
avoid was optimization of our interaction with the Live 
Scoreboards. During research done by the Xbox Live team late 
in our schedule, they found our code was making far too many 
calls to their Scoreboard servers, a capacity problem their 
servers would not have been able to handle after release. 
Though we fixed this problem, it raised significant production 
fears at the end of our schedule. 

In relying on critical technology from external teams, we have 
learned the importance of allocating an adequate schedule buffer 
to accommodate unforeseen problems, maintaining strong com- 
munication with all dependent parties, and gaining a deep under- 
standing of the technology. 

4 Stability of the ghost replay system. In supporting 
# a feature where any Xbox Live user worldwide could 



upload a ghost replay, we needed to be able to guarantee each 
ghost would be a perfect replica of the actual race result. The 
critical nature of this feature caused us to dedicate significant 
attention from our test team. 

The replay subsystem served as the underlying framework for 
recording the ghost data. This legacy system was both complex 
and difficult to consistently debug. One late night two days 
before RTC (release to certification), our testers were in heated 
competition, challenging each other's high score ghosts on one 
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of the arcade cone challenges, with sever- 
al lead changes over the course of a few 
hours. As one score became very difficult 
to beat, one of the testers noticed the 
total Kudos shown in the ghost replay did 
not match the value on the Scoreboard. 
Despite all the months of non-stop test- 
ing, a strong game only hours from ship- 
ping still had a very critical bug some- 
where in the replay system. 

Competitive gameplay is a very valu- 
able part of the testing process during the 
endgame — this was how gamers were 
going to be playing our game! Although 
we fixed it, we could have found that 
bug earlier, and in the future we will also 
push to create more automation for criti- 
cal areas such as this, including hooks 
for specific test scripts, boundary, and 
stress conditions. We'll never be able to 
perfectly emulate the gameplay of mil- 
hons of gamers, but by prioritizing our 
focus, expanding our automation suite, 
and increasing the size and scope of our 
endgame "bug bash" efforts to broader 
internal groups and teams, we'll be better 
armed to find and fix all show-stopping 
bugs before release. 

5 Build process and source 
• control. We had a substantial 
number of assets to manage during content 
creation at Bizarre Creations, including 
over 100 cars with 3D model and dynam- 
ics/handling files, 1 1 constantly evolving 



city models, and over 8,000 audio content 
files. This caused tremendous confusion at 
the end of the project, as our processes 
were not originally planned to handle this 
scope of code and content. 

At the beginning of the project we had 
multiple teams uploading to one game 
image. This led to significant content 
incompatibility problems in the build, 
such as cars using incorrect engine audio, 
city tracks without track-side barriers, 
and old bugs re-appearing as old content 
over-written as new. We planned to solve 
this by splitting up the original game 
image into separate images for city data, 
audio and radio content, car content, and 
all source code. We also planned to cre- 
ate a unique test image, where all content 
would be copied before release to the 
Redmond test team. 

However, splitting the process this way 
ended up causing more harm than good. 
During the endgame, as the Bizarre team 
was doing builds every few days, the test 
image had to be manually updated fre- 
quently. To ensure consistency and speed, 
the team created a step-by-step process 
and set of batch files, to be run in a specif- 
ic order each time. With a game so large 
and server space at a premium, we could 
not use Alienbrain or another file manage- 
ment package. We were forced to dedicate 
one person to this manual drag-and-drop 
process for creating the test image. 

Disasters began to strike as the build 



process began to take longer. Everyone 
was working very long hours, late check- 
ins were made after build smoke tests, 
and additional steps were added in man- 
aging retrieval of assets from multiple 
game images, complicating the build 
process. The test image would often be 
pulled together and posted to the secure 
FTP site, only for the Redmond test team 
to find the build would not run when 
they came in the next morning, losing a 
day of testing on the latest bits. 

Moving forward, the Bizarre team will 
stick to two game images — one image for 
the team to post all code and content, 
and another image for all tested, ship- 
pable content. With less moving parts, 
we expect the process to go more 
smoothly on future projects. 

Final Lap 

In the end, we are all very proud of the 
results we were able to achieve in 
PGR 2, and we hope gamers are too. As 
a team, we were able to deliver on our 
vision and critical priorities for the game. 
We were able to increase our quality bar 
by maintaining a strong balance between 
building upon the core fundamentals of 
PGR gameplay and breaking new ground 
in onhne multiplayer and scoreboards. 
We were also able to deliver the game to 
gamers on time. 

However, no project is perfect, and we 
certainly had our share of hurdles to 
overcome, many self-imposed. We grew a 
lot as a combined Bizarre Creations and 
Microsoft Game Studios team between 
PGR and PGR 2. Our challenge will be 
to continue that growth in the future, to 
learn from the success and failures of our 
past, and to work together to overcome 
future problems as they arise. 

Looking back, the key to our success 
was the team involved in bringing the game 
to life. PGR 2 was built by smart, hard- 
working people working together effectively 
with a high degree of trust, open commu- 
nication channels, and a clear vision and 
goals. Easy things to say, but the magic 
was in the execution, as it will likely con- 
tinue to be in the foreseeable future. # 
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Marketing: 

flecked in 
ogetiier 



For many game developers, "marketing 
guy" ranks near the top of the neces- 
sary evil scale — right after "enter- 
tainment lawyer" and "retail 
buyer." Of course, marketing is a 
necessary evil. Whether you're working with the 
industry's top publishers or just starting out, at 
some point you're going to have to understand, 
embrace, and ultimately partner with that mar- 
keting beast demanding attention in the dark cor- 
ner of your business aspirations. 

First Step: 

Understanding the Beast 

I arketing is communication — it's that simple. When 
I a company puts an emphasis on marketing, it is in fact 
putting an emphasis on communication. Understand this, and 
you realize the old saying "we don't need marketing — our game 
will sell itself" is tantamount to saying, "we don't need to com- 
municate with people — our game will do that on its own." 

It's okay to think of marketing in simple terms, but it's dan- 
gerous to think of it as a simple endeavor. Consumer segments 
have eroded and splintered into an expanding number of tar- 
gets. Adopting a multi-layered campaign, utilizing well-placed 
snipers to support the heavy artillery, is necessary to get your 
message across effectively. Increasingly, the audience is turned 
off by sledgehammer communication tactics; today's consumers 
are empowered consumers, and their patience is evaporating 
with every ad promoting the "most awesome," "most 
advanced," and — worst of all — "most immersive" game ever 
released. Today, your marketing message has to be razor sharp, 
it needs to be emotionally creative, and it better be intelligent 
enough to establish a meaningful connection with consumers, 
or your margin for success will be reduced to a pinhole. 

Next Step: Embracing the Beast 

Putting an emphasis on effective marketing is a fact of life 
in any industry competing for consumer dollars, so why 




fight 
it? If you 
haven't 
done so 
already, it's time to 
embrace the beast. That does- 
n't mean you should develop the market- 
ing; it means you should treat marketing as a priority. In the 
film and music industries, for example, movie studios and 
music labels provide the actual marketing machinery, but the 
successful directors, actors, producers, and musicians make 
marketing a priority throughout their careers. 

Final Step: Partnering with the 
Beast 

Unlike the movie studios, which are similar to one another in 
the way they integrate product development and marketing, 
not all game publishers are alike. Some demand interaction 
between development and marketing; others believe separation 
allows for the least amount of interference. In truth, marketers 
need the partnership — they need to know the product intimately 
if they're going to establish effective positioning and communica- 
tion. And developers need the partnership so they can create the 
appropriate fuel to drive the communication machine, and ulti- 
mately deliver the promise of the marketing claim. 

There are three keys to a true partnership. Number one: 
share information. Numbers two and three: share information 

continued on page 71 
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early and often. That 
means sharing original 
pitch materials, concept 
art, napkin notes, what- 
ever you've got. And, 
yes, that means sharing 
the design document — 
preferably before it's 
finalized. Your marketing partners need more than a list of fea- 
tures; they should be in on the discussion about character traits, 
story arc, level objectives, and everything else from the HUD 
layout to the number of hours the average player needs to com- 
plete your game. In turn, you should get in on the discussion 
about consumer trends, competitive products, market condi- 
tions, and retail initiatives. There is no such thing as starting 
too early on this process. 

Through this process, marketing and development should 
identify the vital "hooks" to your game's positioning as early as 
possible — to make sure the features that support the hooks don't 
disappear during production. Through this process, the two 
groups should identify product placement, promotional partner- 
ship and custom retail opportunities that are organic to your 
game, not just slapped on at the last moment. Through this 
process, the costly and unsettling disconnects that occur between 
the marketing message and the final game can be avoided. And 



opportunities can be seized 
in a timely manner, rather 
than frantically chased or 
missed altogether. 

Cooperation isn't enough. 
Cooperation is the market- 
ing guy politely e-mailing a 
request for assets that get 
incorporated into your milestone schedule. Partnership is market- 
ing and development meeting regularly, establishing positioning 
for the product at the earliest possible stage and developing goals 
for communication initiatives to support the positioning. This 
shouldn't be a relay race, with each person performing his leg of 
the race separately. It's a bobsled run, with everyone packed 
together rocketing down a slippery course that demands a unified 
effort from start to finish. It may seem like an uncomfortable 
notion to some, but it's the only way to keep pace with the com- 
petition and maximize your game's chances for success. 

Craig Relyea I Craig is Executive V.P. of Marketing for Creative 
Domain, a leading Hollywood entertainment marketing agency, 
where he runs the Interactive Entertainment Division and helps 
develop game campaigns for the industry's top publishers. Craig is 
also the former head of Marketing for Dreamworks Interactive and 
V.E. of Worldwide Marketing for Interplay Entertainment. 



Partnership means meeting 
regularly establishing posi- 
tioning, and developing goals 
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